Metadata for a given feature or bundle can be different depending on how it was generated. Particularily when customizing metadata, or when features contribute root files.
Because of this, it is always a good idea to reuse metadata when possible instead of regenerating it based on binary features and bundles that you may not own.
There is an Ant task <p2.repo2runnable> which will transform feature and bundle artifacts into their installed form. Generally speaking, this is the shape we need the plug-ins to be in if we want to be able to compile against them. This task allows us to easily reconsume repositories from other projects in our own build. PDE/Build has built-in integration with this task through the following properties:
| repoBaseLocation | A folder containing repositories to transform. This folder can contain zipped repositories as well as sub-folders which are repositories. |
| transformedRepoLocation | The folder where the tranformed artifacts will be placed. This folder will then become a p2 repository itself. |
build.properties:
repoBaseLocation=${buildDirectory}/inputRepositories
transformedRepoLocation=${buildDirectory}/transformedRepo
customTargets.xml:
<target name="preProcessRepos">
<p2.mirror source="https://download.eclipse.org/releases/galileo" destination="file:${repoBaseLocation}/mirrored">
<iu id="org.eclipse.equinox.p2.user.ui.feature.group" />
<iu id="org.eclipse.cdt.feature.group"/>
</p2.mirror>
<property name="RCP.Repo-3.5RC3" value="https://download.eclipse.org/eclipse/downloads/drops/S-3.5RC3-200905282000/org.eclipse.rcp-p2repo-3.5RC3.zip" />
<property name="Equinox.Repo-3.5RC3" value="https://download.eclipse.org/equinox/drops/S-3.5RC3-200905282000/equinox-SDK-3.5RC3.zip" />
<get src="${RCP.Repo-3.5RC3" dest="${repoBaseLocation}/org.eclipse.rcp-p2repo-3.5RC3.zip" />
<get src="${Equinox.Repo-3.5RC3" dest=""${repoBaseLocation}/eclipse-equinox-3.5RC3.zip" />
</target>
(At the time of of this writing, the location of the 3.5 final zips was not yet known, the URLs here serve as an example only and may not exist at any later date.)
PDE/Build will first call the preProcessRepos custom target, then it will call the repo2runnable ant task to transform those downloaded repositories into a form that can be reused by the build.
The transformedRepoLocation property which defines the location for the output of this transformation also serves as a context repository.
The property p2.context.repos is a comma separated list of repositories that serve as context to the build.
When generating metadata, build will first consult the context repositories to see if there is already existing metadata for the feature or plug-in. If metadata already exists, then it will be copied into the build local repository (${p2.build.repo}) instead of new metadata being generated.
As well, if features, bundles, or products have customized their metadata to depend on something that wasn't included in the build, then PDE/Build will perform a mirror out of the context repositories. This mirror operation will include any IUs that were added to feature or plug-in metadata.