Lately I have built several update sites during Eclipse development – e.g. for the last release of the Debug Visualisation plugin, or some related to VIATRA2 based articles (maybe more details later). They have all one thing in common: they were not created using Update site projects.
In my experience since P2 came as a provisining platform the Update site projects were not the best available solutions: at first (in Ganymede) they did not produce everything P2 needed, while produced legacy information, that triggered a backward compatible mode in the provisining platform (officially the old Update managers site.xml should not be used). Even worse, I experienced some serious errors, when trying to add a new version of the already added plug-ins to the already built update site – in most cases the category definitions were removed (as in Galileo by default all features without category are hidden, this problem is quite serious).
On the other hand, not too long ago classic update sites were also needed to provide update sites for both the Update manager and P2. Today the Update Manager compatibility is not as crucial, as all Eclipse versions supported by eclipse.org use P2, so it is better to use some dedicated P2-based mechanism for Update site creation.
This mechanism is present since Eclipse 3.4 (at least from the command line, as documented in the Eclipse wiki), but is a bit hard to use. Recently I found a somewhat hidden option in the GUI, that provides the P2 metadata generation functionality – just as needed.
To use this, at least one (or possibly more) features are needed – the features are the minimum installable units. When the features are ready and the related plug-ins are attached, the Export wizard has to be invoked with the Deployable Features wizard from the Plug-in Development category.
The deployable features and the destination should be selected as needed (in my experience the directory export makes possible the easiest update site deployment, while the zipped archive allows the easiest direct transport – e.g. for dropins).
The P2-related magic should be initiated on the Options page: if the Generate metadata repository option is selected, as in the screenshot, during the export all metadata needed by P2 is generated.
For categorization of the repository a specific xml-file should be created: by creating a Category Definition from the New… wizard a simple form-based editor can be used to define categories for the installer, that can also be selected using the Export wizard.
Some additional tips and tricks related to the deployment:
- To update existing P2-based update sites, simply point the export destination to the already existing update site. This updates the existing update site – I only tried this using the directory-based output.
- To avoid runtime issues, make sure that the exported plug-in projects use the needed Java version compatibility in the project settings (e.g. if the manifest requires Java 1.5, make sure the project gets compiled in Java 1.5 compatibility mode), as the plug-ins are recompiled using these settings. I managed to get a Java 1.5 compatible project compiled with Java 1.6 compliance settings – the plug-ins even got installed, but did not work in the target computer, instead a hard to debug runtime exception is thrown.
- It is possible to add source boundles by selecting the appropriate checkbox. On the other hand I couldn’t find a way to set the display name of the generated source bundles, and they are shown with the same name as the non-source plug-in, making it hard to distinguish between them during runtime. If you know the solution, please let me know.
In general, this export mechanism works well, without any major issues, I tested in repeatedly with several update sites. Unless for some reason Update manager compatibility is needed, I don’t recommend using Update site projects anymore – simply export your features to deploy.
