Layout of Feature Metadata

PDE Build has always used features as a kind of grouping mechanism specifying what exactly should be built. With p2, this idea of a feature as a group has been extended, resulting a more than a single installable unit (IU) being generated per feature.

From build's perspective, a feature contributes three things:

When using the metadata generator introduced in 3.4, we end up with the following structure for feature "org.example.platform":

org.example.platform.feature.group This is the top level grouping IU for the feature, it will have requirements on all the features and plug-ins that were included and required by the feature.xml. It also includes a requirement on the nested org.example.platform.feature.jar
org.example.platform.feature.jar This is the IU representing the feature jar itself. It has an LDAP filter
"(org.eclipse.update.install.features=true)"
which causes the feature jar to only be installed if the profile defines that property. This IU also has a requirement on the actual org.example.platform_1.0.0.jar artifact.

If the feature does not define "bin.includes" in its build.properties file, then this feature jar IU will not be generated.

Notice this IU structure does not include anything for the root files contributed by the feature. Instead a build using the metadata generation placed all rootfiles together into a single IU and artifact.

New in 3.5 is the p2 publisher. If we use PDE Build's eclipse.gatherFeature task to publish the feature from source, we instead get root file IUs corresponding to the feature that contributed them. In this case, we end up with metadata as follows:

org.example.platform.feature.groupThe top level grouping IU for the feature
org.example.platform.feature.jarThe feature jar IU.
org.example.platform_root
org.example.platform_root.<ws>.<os>.<arch>
These are the root file IUs. The feature.group will include a root IU per platform for which the feature contributes files. The root IU itself has a requirement on the actual binary artifact from a p2 artifact repository (eg binary/org.example.platform_root.gtk.linux.x86_1.0.0) that contains the files.

The use of the new p2 publisher instead of the old metadata generator allows for much finer grain control over how root files are delivered for products.