You may have noticed that feature brandings disappear if you get rid of all the update manager stuff and just use p2 (version 3.4.1). The solution to get the feature brandings back is quite simple: Deploy org.eclipse.update.configurator with your RCP application. But that’s not quite enough. Since org.eclipse.update.configurator is activated lazily, just invoke a static function, e.g.
ConfiguratorUtils.getCurrentPlatformConfiguration() in the startup phase of your application. Or, if you don’t want to have dependencies to org.eclipse.update.configurator, just call Platform.getBundle(“org.eclipse.update.configurator”).start() (Thx Tom :)). The picture below shows the About dialog with feature brandings of my current MP3 Manager. The application was created during a headless build, using p2 director to create the executable
Have Fun!
Kai
Hi, Kai,
An alternative to the static-method call to force activation of the update configurator is to add it to the list of initially-started bundles in the config.ini (the “osgi.bundles” property).
Also, I think it may be necessary to add the following to the config.ini to ensure that the Classic Update doesn’t confuse the Equinox simple-configurator, if your RCP uses the latter:
org.eclipse.update.reconcile=false
Why not simply calling Platform.getBundle(“….”).start()?
Hi Tom,
this is also possible and probably the cleaner solution. But now you would need no dependency to org.eclipse.update.configurator at all, which makes it more difficult for the tooling (e.g. to make sure, that one of your features can check the dependency to org.eclipse.update.configurator to make sure it is in the plug-in list). But considering this a temporary hack, I prefer calling Platform.getBundle(“org.eclipse.update.configurator”).start(). I have edited the original post.
Hi Christian,
how does this work together with the simpleConfigurator p2 is using?
Kai,
The simpleconfigurator can be started by the osgi.bundles property, too. The purpose of the “org.eclipse.update.reconcile=false” property is to ensure that the old UpdateManager doesn’t interfere with the simpleconfigurator. A quote from ZX in the Eclipse newsgroup:
“””
This tells Update to not attempt to discover plug-ins like it promiscuously did in the past. This is needed because in 3.4, p2
is used as the main way to manage bundles… not update.configurator.
“””
Still, p2 seems awfully complicated to me. Is there any tutorial how I can setup an easily upgradeable RCP application?
Phil,
p2 is VERY flexible and “with great flexibility there comes more complexity”.
I don’t have a tutorial, but I wrote another blog that explains how to p2ify the mail template, see http://www.toedter.com/blog/?p=27
Kai,
Thanks for publishing your workaround. I implemented it and was pleased to see my feature branding return. Your description was very helpful.
Thanks
Rich