The package maintainer is responsible for testing the package. The package maintainer should arrange for a number of committers and community members to act as testers. The type and degree of testing may vary but is expected to at least confirm that all the projects basically work together with no immediate problems introduced by being packaged together. In all cases the type of testing and test cases should be documented. EPP will define a process for each package maintainer to identify that the package has been tested, the type of testing and that the package is ready for download.

+

The package maintainer is responsible for testing the package. The package maintainer should arrange for a number of committers and community members to act as testers. The type and degree of testing may vary but is expected to at least confirm that all the projects basically work together with no immediate problems introduced by being packaged together. In all cases the type of testing and test cases should be documented. EPP will define a process for each package maintainer to identify that the package has been tested, the type of testing and that the package is ready for download. The package maintainer needs to send a +1 vote before a package can be released. This applies not only to releases, but also to milestones and release candidates.

Contents

Creation of a Package

To create a package a project leader or committer must agree to be a package maintainer. The package maintainer is responsible for defining the contents of the package and arrange for testing of the package and will become a committer on the EPP project.

To define a package the package maintainer will need to specify the package contents based on an Eclipse product definition, an Eclipse feature, and an branding plug-in. Examples can be found in the EPP Packages Git repository. The EPP team will then begin to automatically build the package based on this configuration.

What can be included in a Package?

Packages must only contain code from Eclipse projects from the Simultaneous Release.

Packages should usually only contain code from projects that have passed their 1.0 creation review, and if exceptions are found, the code must still have passed an Eclipse Release Review.

Packages should attempt to include code from a variety of projects, while maintaining a coherent theme to the package, balanced with download and install size, fitting with the desires and suggestions of the community.

By default, each package will contain the Eclipse Market Place Client (MPC). The EPP build process will automatically include it in the package, so the package maintainer does not need to specify it.

Adding components to a package

When extending a package it's helpful to consider the impact of new components:

What is the impact on the download size of the package if the new component is included?

Does the new component depend on components (e.g. PDE) that are not already part of the package?

Does the new component or any of its dependencies have incubation status?

Does the new component require additional components that would not be shipped as part of the package (e.g. an external runtime)?

Does the new component log any output to the console?

Does the new component contribute a startup extension?

Does the new component contribute any (modal) dialogs that are visible on startup?

What is the runtime impact if the new component is not used?

Which UI contributions if any does the new component add to the various perspectives?

Testing of a Package

The package maintainer is responsible for testing the package. The package maintainer should arrange for a number of committers and community members to act as testers. The type and degree of testing may vary but is expected to at least confirm that all the projects basically work together with no immediate problems introduced by being packaged together. In all cases the type of testing and test cases should be documented. EPP will define a process for each package maintainer to identify that the package has been tested, the type of testing and that the package is ready for download. The package maintainer needs to send a +1 vote before a package can be released. This applies not only to releases, but also to milestones and release candidates.

Publishing of Packages

A web site will be created to publish the different packages. This new web site will be directly accessible from the download page. The packaging page will show all the available packages and use social networking techniques to influence the order and display of the packages. For instance, the number of time a package is download will be visible, the names of the project maintainers and testers will be associated with the project or maybe individuals can vote/recommend a package. The Eclipse Foundation will also continue to list 4-5 packages directly on the download page.

How to Get Started?

If you would like to create a package, we ask that you open a bugzilla request for EPP, using the ‘package content’ component [EPP]. In the bugzilla bug, please specify a description of the package you would like to create, including the intended targeted user and the feature set of the package. You will then need to create a package configuration file together with the EPP team and then specify the location of the file. You will then need to create an package configuration file and then specify the location of the file. Please add this location to the bugzilla request. EPP builds the packages on a nightly basis, so once your package is defined, we will start building it.

EPP is also releasing packages for each milestone and release candidate for Ganymede. If you would like your package to be built for M5, we ask that you please have it defined before February 11.

We are just starting this process so your feedback and support is welcome. It will take sometime to make it perfect but the intention is to have a number of packages available in time for the Ganymede release.

Experience in creating a new package for Indigo

The Parallel Tools Platform has created a new package 'parallel' for Indigo EPP. Documenting the steps we did here, since some of the above may be outdated.

Open a bugzilla request for EPP, using the ‘package content’ component [EPP] establishing intent to create a new package and outlining its contents and audience. You must commit to test your package when it is built, and subscribe to epp-dev mailing list and be responsive to requests there.

Create two eclipse projects, a feature (package) and bundle (branding plug-in) pair. The existing epp projects are located in CVS server: dev.eclipse.org /cvsroot/technology under org.eclipse.epp in the 'packages' folder.

PTP chose to clone the two projects from CPP since we planned to use that plus more. So copied org.eclipse.epp.package.cpp.feature (package info) and org.eclipse.epp.package.cpp (branding).

Changed project names and all references to 'cpp' to our package identifier 'parallel'

Added features specific to PTP

Attach zipped projects to the bug as a patch

Note that the features to be included are listed as dependencies in the feature.xml of the package feature project.

Note also that any features here MUST be part of the Indigo build - so must already be a part of Indigo. (For example, some optional features of CDT are not, and users must go to the CDT-specific update site, not the Helios or Indigo update sites, to install these.)