Building p2 Repositories and Products

PDE/Build has built in support for publishing p2 metadata using the new p2 Publisher. 3.4-style integration with the old metadata generator still works, but does not support newer features like the customization of metadata.

The new publisher integration gathers your features and bundles from source and publishes them directly to a p2 repository. To use the new functionality, the builder should define the property:

p2.gathering = true

Setting this property will change the build in significant manner:

See the separate feature and product build help pages for more detail on those types of builds.

Overview of the changes

The build's local repository

During the build, all metadata and artifacts will be published into a build repository defined by the property p2.build.repo. This property should specify a URI, the default value for this is file:${buildDirectory}/buildRepo.

Once all the metadata and artifacts are published into this repository, the final assemble and packaging scripts will mirror and/or install from this repository into the locations that will become the archives produced by the build. This final mirroring and installation can be skipped using skipMirroring and skipDirector properties, in which case the build results would all just be in the build repository.

Generated build.xml : gathering vs publishing

In the generated build.xml for features and plugins there is a target gather.bin.parts which was responsible for gathering the contents of the feature/plug-in and copying them to a final directory to be jared (or not) and included in the build results. When using p2.gathering=true, we instead publish the feature/plug-in directly into a p2 repository. That is, we are using p2 to gather the binary artifacts directly from the source (this is where the name of the property comes from).

This is done using a new target named publish.bin.parts which uses a new ant tasks contributed by PDE/Build. In old style builds, calling gather.bin.parts was done by delegating through the feature structure. Calling publish.bin.parts is instead done directly from a new assemble p2 script that is generated.

Rootfiles contributed by features

Old style integrations grouped all the rootfiles contributed by all the features in the build into a single root file installable unit and artifact (which may have been named for a product). With the new publishing support, root files are instead associated with the feature that contributed them. See the feature metadata layout page for more details.

The assemble scripts

Old style integration was done by calling the metadata generator on the binary results during the assembly and packaging process. When using p2.gathering=true there is a new assemble.<feature>.p2.xml script.

This script will invoke the publish.bin.parts for all features and bundles being built. It will also publish metadata for all pre-existing binary features and plug-ins, as well as publishing metadata for products.

At the end of the p2 assemble script, before the remaining assemble and package scripts are called, we have a complete repository with the full results of the build. The remaining assemble and package scripts are simply slicing up the repository and/or performing installs using the p2 director to create the final archives which are the results of the build.