Updating RCP applications – don’t “use osgi.configuration.cascaded=true”

Recently, I’ve thought that I’ve understood how the update mechanism of an RCP application works. I don’t. Though the articles from Lars Vogel and Ralf Ebert about updating RCP applications were a great help, something went completely wrong with OpenChrom. And I definitively had no clue where to start searching. Everything worked fine updating additional installed plug-ins, but the base RCP couldn’t be updated. Each time the update mechanism told me, that no updates are available.

No updates were found

Anyhow, the update sites are accessible in the same way it works for the plug-ins. No success. Then I exported the product and uploaded the created metadata repository on my server. After adding the update site “http://www.openchrom.net/main/repositories/0.6.x/repository” to the list of “Available Software Sites” and running the update again, I’ve got the following error message.

Only one of the following can be installed at once

Aha, the first hint “Only one of the following can be installed at once“. It brought me to the Bug 322344 which led me to the assumption, that it has something to do with the “Multi-user install” settings. Hence, I had a look at the Eclipse runtime options and the settings used in OpenChrom’s options file “openchrom.ini”.

...
-Dosgi.install.area.readOnly
-Dosgi.configuration.area=@user.home/.openchrom/0.6.0/OpenChrom/configuration
-Dosgi.instance.area.default=@user.home/OpenChrom/workspace
...

I’ve used a distinct configuration area to allow installations of user-specific plug-ins, see Eclipse multi-user installs. It works fine for such a purpose but not for updating the base RCP. Time to tinker with these settings. Finally, I’ve found a setting that works under Windows, Linux and MAC OS X.

...
-Dosgi.install.area.readOnly
-Dosgi.instance.area=@user.home/OpenChrom/workspace
-Dosgi.user.area=@user.home/.openchrom/0.6.0/Settings
...

It works so far and I’ve learned to not use “osgi.configuration.cascaded=true” if the base RCP application shall be updatable. But honestly, I’d really like to fully understand how multi-user install configurations and the p2 update mechanism are working. Is there maybe someone, who has a good tutorial or white-paper?

Advertisements

About Philip Wenig

Founder of OpenChrom
This entry was posted in Uncategorized. Bookmark the permalink.

7 Responses to Updating RCP applications – don’t “use osgi.configuration.cascaded=true”

  1. eiswind says:

    Hi Phillip, p2 seems to be always good for a headache.

  2. jaloncad says:

    Hi,
    We had the same problem while building our RCP/Helios own distribution. Using multiple configurations as you described will make the core of platform imposible to update.

    As multiple configurations has a lot of beneficts, like: multiple versions of the same product in each configuration, clean base configuration, auto-update, we continue investigating and we resolved with the following:

    In our .ini file we set the ‘osgi.configuration.area.default’ pointing to ../default_area and also created our launcher class. In .ini file:

    -startup
    plugins/com.bb.aa.launcher_1.0.2.jar

    Our launcher class launches the platform without taking care of configuration parameter if there are updates for the core features, if any it uses p2 to update them and restart the platform with the configuration parameter.

    There is also a bug, with the synchronization of the bundles.info between base configuration and it’s childs. (http://wiki.eclipse.org/Equinox/p2/Shared_Install#User.27s_Locally_Installed_Features_Lost_on_Base_Update_.28Bug_304132.29)

    Rgds,
    Juan.

  3. Daniel says:

    Hi Phillip,

    just recently I switched from plugin based builds to feature based and received that error (“Only one of the following can be installed at once”), too.
    I know, that I don’t use that specific setting (but maybe it’s “true” by default, I don’t know).
    The main difference is, that I define “-data @noDefault” to allow the user to create an own workspace, just like Eclipse does (I real live, the customer (about 10 users) is sharing one workspace via a network folder, but that doesn’t matter – the workspace is locked as long as one instance is already operating on it).

    When you wrote the article I was quit optimistic, that this might be the clue, but I only found some time to look into it today, though.
    Can you specify, where the parameter should be set (at least set to “false”)? Is it the programs .ini file or the config.ini within the workspaces “configuration” folder?

    Thanks,
    Daniel

    • eselmeister says:

      Hi Daniel,

      there are principally two places where to set the parameters.

      A) If you’re using a feature based build, you may also use a “Product Configuration” file. The product configuration editor offers a tab called “Launching”. You can specify “Program Arguments” and “VM Arguments” under “Launching Arguments”. Use the “VM Arguments” to store e.g. “-Dosgi.install.area.readOnly”.

      B) Use the product.ini of an exported RCP to define user specific parameters.

      • Daniel says:

        Hi and thanks for your reply,

        I’m using .product files for both plugin and feature based products. I already use the Program Argument “-data @noDefault” (without this, I never got the custom Workspace to be used by the program) and the VM Argument “-XX:MaxPermSize=1024m -Xms256m -Xmx1024m”.

        The question is: Which parameter to use, and what kind of parameter it is.

        I guess, “-Dosgi.install.area.readOnly” might not be a bad idea, but would it be usefull to set “-Dosgi.configuration.cascaded=false” ???

        Thanks again,
        Daniel

      • eselmeister says:

        Hi Daniel,

        that’s exactly my problem. Some parameters are implicit, some parameters do exclude others. It’s not really clear for me how it works until now. Hence, a great challenge to learn new things :-).

      • Daniel says:

        Ok, sounds like a challenge 😉
        Good luck with that!
        I will try as well, because your blog at least gave me some hints where to look at all!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s