Type: User Story
Affects Version/s: None
Fix Version/s: 0.11.0
Currently, the data flow for eclipse-repository is quite labyrinthine - and has hence certain limitations. The aim of this user story is to clean up the concept for how the results of the local reactor are consumed.
In the current implementation, the p2 repository content of the eclipse-repository is obtained in the following way:
- Product and category definitions in the eclipse-repository module are simply published into the p2 repository.
- The jars of the features and bundle that are included (as described here) are copied and the p2 repository information is generated with the FeaturesAndBundlesPublisher. The problem here is, that the feature.jar doesn't contain any information about root files, so that this approach cannot take root files into account (see also the rejected proposal #3 here).
In the current implementation, the really complicated situation is when a product is installed with the goal "materialize-products". In this case, the following p2 metadata and p2 artifact sources are used:
- The metatada from the target platform resolution, computed when determining the build order. The artifact from the local reactor are pre-published into this metadata repository. Pre-published means that for some types (notably eclipse-feature), a limited "dependencies only" publisher is used. This concept has been spoiled in part when implementing
TYCHO-188- e.g. the feature jars are now also published, although they are not needed for build order computation (cf. 93c53b10). This data is propagated to eclipse-repository via the MetadataSerializable.
- The p2 metadata and p2 artifacts repository created as the main (Maven) artifact of eclipse-repository.
- The local Maven artifact repository as a p2 artifact repository, implemented in LocalArtifactRepository. If the eclipse-repository does not include all bundles from the local reactor, this is the way how the missing p2 artifacts from the local reactor are read. As a consequence, eclipse-repository currently only works (in this case) if Maven is called with [[install]].
As part of this user story, the following things shall be changed:
- The p2 metadata for each module is created in the module build itself. There is probably nothing to do for that because the maven-p2-plugin already generates the needed data and stores it in files p2content.xml and p2artifacts.xml
- eclipse-repository mirrors the p2 data from the p2content.xml and p2artifacts.xml for the included features and bundles.
- For features an plugins from the target platform, the p2 metadata is obtained via the MetadataSerializable as today. (However all p2 metadata about the local reactor will be filtered out when serializing.) The LocalArtifactRepository will also be used as p2 artifact repository for the non-local features and plugins. (Again, we may need some filtering.)
These changes pave the way for the following improvements:
- Root files can be published as part of the eclipse-feature module build (to be done in
TYCHO-465). The p2 metadata about these root files will no longer be lost when including the feature in an eclipse-repository.
- The coupling with the build order computation is significantly reduced.
- mvn package should work properly for eclipse-repository.