PDE Build Integration with p2
Generating p2 metadata page in the Platform Plugin-in Developer Guide for details on p2 metadata generation. Generating metadata by itself it not sufficient to create a p2-enabled product. To do this you must perform an actual p2 install from the generated metadata. See the
p2 director documentation for details on how to perform this install from a headless script.
It is possible to generate p2 metadata with manual calls to the p2 metadata generator in any of PDE/Build's custom tasks (see
Customizing a Headless Build).
However, PDE/Build does provide integration with p2 via the following properties:
|Set to true to turn on p2 metadata generation. The ant scripts are based on the existence of this property and not the value. To turn off metadata generation, the property must be removed and not just set to false.
In the build scripts, calls to p2 targets are generated when the p2 bundle org.eclipse.equinox.p2.metadata.generator and its dependencies are present in the Eclipse that is running the build.
These p2 targets are conditional on the generate.p2.metadata property.
|Specify a file: URL giving the location of the p2 metadata and artifact repositories to publish to. It is common, but not necessary for the artifact repository to use the same location as the metadata repository.
|Optional. Specify a names for the generator p2 repositories.
When using a repository that already exists, the existing name of the repository will not be changed.
If not specified, p2 will name the repositories according to their location.
|Set the flavor for the p2 metadata. When metadata is generated for the Eclipse SDK, a flavor of "tooling" is used.
|Set to true to publish jars into the artifact repository. If set to false, then artifact metadata is generated but the jars are not copied to the artifact repository. WARNING: when set to true, make sure that the p2.artifact.repo is not the same location as the assembly directories used by PDE/Build, otherwise jars might end up deleted!
|Specify the name and version for the root IU that will contain everything that was built.
If a .product file is specified in the build, then these properties will be ignored. Instead, when a .product file is available the root name and version will be the product id and version from the .product file. See below for more information.
Metadata Generation for Products
When running a build with a product file set in the top level build configuration build.properties file (both in builds using the productBuild.xml and the normal build.xml), then PDE/Build will automatically generate metadata for that product.
In addition to creating Installable Units for all the features and bundles, this will also create the following product Installable Units:
- A top level Product IU using the product-id and the product version. If no version is set in the .product file, "1.0.0" is used.
- Configuration Units that set start level information for individual bundles as specified in the config.ini used for the product.
- Configuration Units that set program and vm arguments for the product's launcher .ini file.
- Configuration Units that add entries to the config.ini based on the config.ini used for the product.
- Installable Units to deliver the branded launcher as well as any root files.
- Configuration Units that set arguments in the launcher .ini file specifying -startup and --launcher.library to enable installing the product with a bundle pool.
With all of these generated Installable Units, it is possible to use p2 to install the complete product out of the repository.
PDE/Build is essentially calling the metadata generation task provided by p2 at certain points during the build. It is likely that during a build there is never a single point in time where all build artifacts exist on disk at the same place. Therefore, it would be necessary to either call the p2 metadata generater on the final archives or, as an optimization, call it multiple times throughout the build.
Metadata generation will occur throughout the assemble and packaging phases. This is true for both normal builds and
packager builds. To illustrate, for a product build using productBuild.xml, the following scripts will be generated (assuming configs=win32,win32,x86 & linux,gtk,ppc):
Assemble scripts collect features and plug-ins that were built along with associated root files. Package scripts collect pre built binary features and plug-ins. The platform specific scripts collect the pieces for those particular configurations and the "all" scripts delegate to each of the platform specific scripts.
p2 generation calls will occur as follows:
- assemble win32.win32.x86 : Generate metadata for collected features and plug-ins for windows.
- assemble win32.win32.x86 : Second call to generated metadata for collected root files for windows.
- assemble linux.gtk.ppc : Generate metadata for collected features and plug-ins for linux.
- assemble linux.gtk.ppc : Second call to generated metadata for collected root files for linux.
- assemble all : If not running the packager: Generate metadata for a root installable unit that includes everything above.
- package win32.win32.x86 : Generate metadata for packaged features and plug-ins for windows.
- package win32.win32.x86 : Second call to generated metadata on rootfiles from packaging windows.
- package linux.gtk.ppc : Generate metadata for packaged features and plug-ins for linux.
- package linux.gtk.ppc : Second call to generated metadata on rootfiles from packaging for linux.
- package all : Generate metadata for a root installable unit that includes everything above.
The p2 metadata generator task supports incremental generation, each call to the p2 metadata generated is done with mode=incremental, the final call to generate the root installable unit will run with mode="final"