Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

EPP/Obsolete/Wizard/Proposal for better P2 Integration

This page outlines a proposal for an improved P2 integration for the EPP Wizard. Note: This proposal has been implemented into the EPP Wizard code base.

Metadata generation from IUs

Currently (i.e. as of 2008-08-01) the epp p2 metadata repository is generated from data in the eppmodel.xml. The format used is basically the old site.xml format embedded in the eppmodel.xml. This information is then used by the P2 metadata generator to create the content.xml. The problem with this approach that the metadata generator needs a "base" directory (-base) with plugins and features, making it impractical for integration and deployment with the Eclipse/Ganymede P2 repositories.

A more lightweight approach would be to use individual IUs for each separate selectable component in the Wizard. This would allow a simple creation of the epp p2 metadata repository (basically just an aggregation of these IUs). It would also make IU component maintenance easier for the respective maintainers because the IUs are decoupled and could be edited and replaced independently. With all the meta information present in the p2 repository, the wizard itself could use that same repository to obtain the component information, with the eppmodel.xml only providing structural information (i.e. what component is in which group on which page of the wizard). This would enforce a separation of concerns (content vs. presentation) and would make maintenance much easier for all involved parties.

Automatic IU generation for EPP packages

The existing Package definitions (cf. EPP/Obsolete/Configuration File Format) created and used by the EPP can be transformed into IU definition files that can be consumed by the metadata generator to produce installer packages almost identical to the traditional "standard" package files. There currently exists a proof-of-concept implementation that performs such a transformation using xslt.

Back to the top