Friday, May 29, 2009

Target Platform Provisioning

For CDO and Net4j we used to have a special Ant script that downloads a well-defined set of dependencies and installs them into a target platform that is contained by the metadata section of the wokspace. The same script also cares to setup a well-defined API baseline. While this was handy in the absence of other mechanisms it always suffered from some issues:

  • Maintenance burden to keep the versions up to date. Since the automated build is designed differently this was redundant and prone of errors.
  • 3rd party bundles were taken from SpringSource which is not a p2 repository. The SpringSource bundles make heavy use of the "uses" manifest header attribute, often resulting in broken configurations.
Some time after reading Chris's blog about the new target platform provisioning I started to play with it and it really was easy. I came up with a simple target definition for CDO:

Initially I started with a "Directory" provisioner for the SpringSource bundles but then I decided to create an own p2 repository at Net4j and CDO Plus Updates. This can now be used to provision your IDE as well as parts of the CDO target platform. Pressing "Set as Target Platform" did its job without problems: In the end all bundles compiled without errors.

So, in the future I'd really like to use this great mechanism for provisioning my target platform but unfortunately there's a show stopper: The target definition carries explicit versions for all the configured features and there's currently no way to update them automatically. I'd really wish it was as easy as my IDE updates are nowadays but it turns out that, once the repositories offer newer versions, not only these are not picked up but the target definition editor even refuses to list the old features. I had to start from scratch and this is certainly no better than what we had before.

There's a bugzilla to track the addition of an update button in the target provisioner. I guess that would finally give me what I need to make use of the whole new target platform provisioning. Anyway, this is great stuff and I appreciate very much all the effort that has been spent so far. Thank you guys!


  1. The "update" button seems to be a popular request. Until then, you can "Edit..." the sites in your target definition and manually update them to the next/newer version when needed. In terms of sharing a target definition with a team, there are likely different use cases:
    * sharing a specific version of target
    * sharing the "newest" version
    When sharing a specific version, it allows you to control when the target changes/upgrades, rather than having it change out from underneath you at unknown intervals.

  2. Darin,

    Thank you for the infos! As I mentioned I occasionally experienced full feature config loss with the Edit button. I have the feeling that it might be related to the initial "resolving definition" phase of the target editor. After that's finished it seems to work better. I'll keep an eye on it and report via bugzilla if the problem persists.