# 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:

- Feature builds produce a single p2 repository that is a group of all the configurations being built.
- Product builds produce a properly installed fully enabled p2 product. (And optionally the corresponding repository.)

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.