This page describes a deprecated old way of integrating with p2. See the "Building p2 Repositories and Products" page for the recommended methods to build with p2. The properties described below work using a backward compability layer and do not support any new features that may be added to the p2 publisher.
See the 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:
generate.p2.metadata |
(DEPRECATED, use p2.gathering instead) 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. |
p2.metadata.repo |
Specify a file: URI 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. Example:
p2.metadata.repo=file:${buildDirectory}/repository
p2.artifact.repo=file:${buildDirectory}/repository
|
p2.metadata.repo.name |
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. |
p2.flavor |
Set the flavor for the p2 metadata. When metadata is generated for the Eclipse SDK, a flavor of "tooling" is used. |
p2.publish.artifacts |
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! |
p2.root.name |
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. |
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:
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:
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"