Adventures with p2 composites

Earlier this year, we changed the way Oracle Enterprise Pack for Eclipse (OEPE) repository is packaged from a monolithic repository to a composite of many component repositories. We made this change in order to have greater flexibility in how frequently or infrequently we update the various components of the product.

1. Some of our components change rarely and some don’t change at all after the initial release. For instance, there is no point in re-releasing Java EE 7 documentation component with every OEPE release nor is there any point in having a separate copy of this component for every release kept on the download server.
2. Some of our components are libraries from other products that update on their own schedule. For instance, we need the ability to update Oracle Mobile Application Framework and Oracle Cloud SDKs as new versions become available without orchestrating an entire OEPE release.

When it comes to assembling the composite repository, there are two types of components:

1. Visible to the user
2. Available for dependency resolution, but not visible to the user

The components that should be visible to the user are easy to handle. When p2 merges the child repositories listed in the composite repository metadata, it preserves the categorization of features as specified by the child repositories. The effect is a union of visible features.

The components that should be available for dependency resolution, but not visible to the user are harder to handle.

One approach would be to strip the categorization from the component repository and add the component repository to the composite. This is rarely a practical solution as the component repository may be hosted by a third party or there may be a need to retain the utility of being able to offer it separately, which requires features to be visible to the user.

Another approach is to utilize the repository references feature. This is the approach that we settled on, but there are some downsides.

1. Bug 455422 - Unlike child repositories of a composite, referenced repositories are added to Eclipse repository registry. If you reference many components, the repository registry will bloat very quickly, something that the user is unlikely to appreciate. Further, the user can disable referenced repositories in the registry, interfering with the proper operation of you repository. One partial workaround is to create a separate composite repository for the dependencies and then use a repository reference to point to the dependencies composite. The benefit of this indirection is that you add only one extra repository to the repository registry, regardless of how many repositories you need to reference.
2. Bug 409734 - Unlike child repositories of a composite, a referenced repository cannot be a relative URL. Depending on your build and release process, you may need to update repository references in various content.xml files when moving repositories around.

This concludes our adventures. Don’t forget to tip the guide.