EPP/Obsolete/How to create a package

Note: The contents of this page is obsolete, but it may still contain some interesting tid-bits.

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 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:

• Is the component of good enough quality from all perspectives (usability, performance, API and extension rules, governance...)
• 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

The EPP packages are published on the packaging page www.eclipse.org/downloads/packages. The packaging page shows all the available packages and uses social networking techniques to influence the order and display of the packages. For instance, the number of time a package is download is visible, the names of the project maintainers and testers will be associated with the package. The Eclipse Foundation will also continue to list packages directly on the main download page www.eclipse.org/downloads.

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 the package projects together with the EPP team. 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 the yearly Simultaneous Release. If you would like your package to be included in the next Simultaneous Release, we ask that you please have it defined before M6.

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.

1. 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.
   • The parallel epp package bug is located at [1] for reference.
2. Create two eclipse projects, a feature (package) and bundle (branding plug-in) pair. The existing EPP projects are located in Git: http://git.eclipse.org/c/epp/org.eclipse.epp.packages.git/
   • 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
3. 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 Simultaneous Release build - so must already be a part of Kepler. (For example, some optional features of CDT were originally not, and users must go to the CDT-specific update site, not the Kepler update site, to install these.)