There has been a lot of talk lately about p2. Using p2, you can:
- Validate repositories
- Describe dependencies
- Manage your configurations
However, all this talk about p2 assumes you have p2 enabled repositories.
Now p2 is able parse and understand traditional update sites, but this far from ideal for several reasons:
- The parsing / processing happens each time a user hits your update site. This means that jars are D/L and metadata is produced while users wait.
- Not all the information is available on an update site
- The cool kids already have p2 enabled repositories
So this begs the question: How do I provide a “p2-ified” repository for my content?
In Eclipse 3.4 the answer was the metadata generator. The metadata generator was able to look at an Eclipse install, scrounge around the filesystem, crack open jars, and build a p2 repository from what it found. While this worked, it was very much tied to the way Eclipse is laid out on disk. (OSGi bundles had to be in a directory called plugins, start levels had to be listed in eclipse specific locations, etc…).
The metadata generator was written to give the p2 team the original “wad” of metadata so the rest of p2 could be assembled. The generator served it’s purpose.
In Eclipse 3.5, the p2 publisher was developed. The publisher is the means by which deployable entities get added to repositories. The publisher can be used in four ways:
- As a set of headless Eclipse applications
- As a set of Ant tasks
- Through its extensible API
- Within PDE Build
Today I’m going to discuss the first two:
Headless Eclipse Applications
There are four headless publisher application: 1. UpdateSite, 2. Features and Bundles, 3. Product, and 4. Category Publisher. Each of these publisher applications are responsible for creating metadata from different sources. For example, the Features and Bundles Publisher Application generates metadata from pre-built features and bundles.
This can be invoked as follows:
java -jar /plugins/org.eclipse.equinox.launcher_*.jar -application org.eclipse.equinox.p2.publisher.FeaturesAndBundlesPublisher -metadataRepository file://repository -artifactRepository file://repository -bundles / -configs gtk.linux.x86 -compress -publishArtifacts
This will create both a metadata and artifact repository for the bundles located in <location of your bundles>. The repositories will be compressed and the artifacts (the actual bits) will be published.
In addition to the headless applications, the publisher can also be used directly in your Ant scripts. There are currently two Ant tasks provided by the publisher: 1. Features and Bundles, and 2. Product Publisher. These tasks do the same thing as their headless application counterpart.
For example, the feature and bundles task can be written as follows:
<p2.publish.featuresAndBundles metadataRepository="file:/repository/location" artifactRepository="file:/repository/location" publishArtifacts="true" compress="true" source="/bundles/and/features/location/">
In this case the source tag is used, meaning that the publisher will look for both the features and bundles in the /bundles/and/features/location. It will look in a plugins directory for bundles and a features directory for features. Again, the repositories will be compressed and the artifacts published. You can use a nested <bundles> or <features> tag if you want to specify specific bundle or feature locations.
<p2.publish.featuresAndBundles metadataRepository="file:/repository/location" artifactRepository="file:/repository/location" publishArtifacts="true" compress="true"> <bundles dir="/bundle/location"/> </p2.publish.featuresAndBundles>
For more information on what the publisher is, how to use it, and how you can get involved, please read our wiki page.