Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » P2 » Questions re. update sites for read-only/shared installs (might be repost, first time around :) )(Questions re. update sites for read-only/shared installs and issues when updating Eclipse root files (might be repost, first time around :) ))
Questions re. update sites for read-only/shared installs (might be repost, first time around :) ) [message #1278547] Thu, 27 March 2014 13:39 Go to next message
Christa ClaessonFriend
Messages: 4
Registered: March 2014
Junior Member
Hi Smile

I'm looking for some advice on how to structure update sites so that updating read-only / shared installs will work without updating / backing up Eclipse root files.

Our application is a Eclipse based RCP based fronted for a ERP system that can be updated using update sites for client, branding and localization updates.

This works perfectly in the scenario where the users have read/write access to the installation folder of the Eclipse based RCP application, both on Mac OS X and on Windows.

If the users only have read-only access to the folder of the Eclipse based RCP application (whether it's on Mac OS X or Windows) then the update fails when the P2 update mechanism tries to backup the Eclipse native launcher (Eclipse.exe) as part of a shared install update.

Our Eclipse based RCP client is based on .product, .features and various plug-in's. Everything is referenced from the .product / .feature file(s). We have tried various experiments and have found out that if we no not change the version in the .product file, then the P2 update mechanism do not touch / back's up the Eclipse native launcher, unfortunately this also has the side effect of not updating any of the .feature(s) / .plugin(s) either ...

Has anybody tried using the P2 update mechanism in read-only installs ? And is there any advice available of how to structure update sites so that updating a read-only Eclipse RCP application do *not* touch the Eclipse root files and folders ?


FOLLOW UP (6 May 2014):

Hi Again Smile

In in last few weeks I have been investigating the issues that our update sites have with updating shared installs. What I have come up with might be interesting for others:

1) I have split our applications into two: one part that contains the Eclipse "core" files and the RCP feature etc. etc., generally everything that is not expected to change between "minor" product releases. Another part contains the functionality of our application, which is more prone to be updated in "minor" product releases. Our application then consists of two major features: one that contains the RCP etc. etc. and another that contains the classes of "our" application.

2) The feature that contains "our" application is marked as "optional". This makes it possible to update it without updating the "product" and thus prevents P2 from writing / updating the Eclipse "core" files.

3) The feature that contains "our" application is associated with it's own "Category" in P2 parlance. If this was not the case, then the feature is simply ignored by the P2 update mechanism.

So, to sum things up we have something like:

   MyApp.product (includes native launcher artifacts and JRE)
     MyRCPEtc.feature
       RCP.feature
       ...

     MyApplication.feature (optional and categorized)
       MyPlugin1.plugin
       MyPlugin2.plugin
       ...
       MyPluginN.plugin

4) The associated update site is divided in two parts: one for read/write P2 updates and one for read-only P2 updates. The read/write part of the update site is just our usual update site that contains the complete product. The read-only part of the update site only contains the MyApplication.feature from above. What happens during runtime is that our application the checks if its installed in a read-only environment or not and chooses the relevant part of the update site. This prevents the client from attempting to update the Eclipse "core" files when in a read-only environment.


CURRENT STATUS:

Everything from 1) -> 4) works and we can update a read-only version of our application. The only issue left is that the updated read-only application do not pick up the updated plug-ins in the ".eclipse" folder. So it still runs as if not updated. I have found out that this behavior is caused by a precondition in the:

  org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl

class that handles the "Bundles.info" file from the shared and user specific "../configuration/org.eclipse.equinox.simpleconfigurator/" folders. In the "getConfigurationURL" method of this class, there is the precondition that the contents of the user specific "Bundles.info" file must be a superset of the shared (read-only) "Bundles.info" file. If this is not the case, then the shared "Bundles.info" file is used and the just updated plug-ins / features are effectively ignored.

The problem with this precondition seems to be that if a updated feature includes "singleton" plug-in's then only the latest version is listed in the user specific "Bundles.info" file. This makes it impossible for the user specific "Bundles.info" file to be a superset of the shared "Bundles.info" file, e.g. if a "singleton" plug-in "A", version 1.0.0 is updated to version 2.0.0 then only version 2.0.0 is listed in the user specific "Bundles.info" file.

If I manually add the version 1.0.0 to the user specific "Bundles.info" file, then our application picks up all the updates correctly.

So, the question is: is this a unfortunate clash of the handling the "Bundles.info" file and the inclusion of "singleton" plug-in's ? At least in our case it prevents the read-only update from working. Has anyone else solved this issue ? Or has anyone experienced this issue before ?


FOLLOW UP #2

I can now see that the code of the "getConfigurationURL" methods has recently been completely rewritten by the patch:

  http://git.eclipse.org/c/equinox/rt.equinox.p2.git/diff/bundles/org.eclipse.equinox.simpleconfigurator/src/org/eclipse/equinox/internal/simpleconfigurator/SimpleConfiguratorImpl.java?id=b86b21139a5367412cd51e86d359af33b0c03c3c

I will try to use a newer version of the org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl class and see if this solves the remaining issue (we are currently using version 1.0.301 of the org.eclipse.equinox.internal.simpleconfigurator plugin).

[Updated on: Tue, 06 May 2014 12:57]

Report message to a moderator

Re: Questions re. update sites for read-only/shared installs (might be repost, first time around :) [message #1336273 is a reply to message #1278547] Tue, 06 May 2014 10:07 Go to previous messageGo to next message
Christa ClaessonFriend
Messages: 4
Registered: March 2014
Junior Member
Hi All Smile

Just updated the message with the latests finding and status, might be interesting reading

Re: Questions re. update sites for read-only/shared installs (might be repost, first time around :) [message #1339088 is a reply to message #1336273] Wed, 07 May 2014 14:09 Go to previous messageGo to next message
Christa ClaessonFriend
Messages: 4
Registered: March 2014
Junior Member
Hi All Smile

RE: FOLLOW UP #2

Using the newest version of:

  org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl

seems to solve the "singleton" plug-in issues as the "superset" test in: "getConfigurationURL" has been removed in the newest version and replaced by a timestamp check.

So what to do ? Our product is based on the 3.8.1 target platform and the fixes in "SimpleConfiguratorImpl" were released as part of the 4.3 target platform, so I'll probably have to see if I can reuse the new plug-in's in 3.8.1 or back port the fixes...More later Smile
Re: Questions re. update sites for read-only/shared installs (might be repost, first time around :) [message #1355037 is a reply to message #1339088] Wed, 14 May 2014 14:43 Go to previous message
Christa ClaessonFriend
Messages: 4
Registered: March 2014
Junior Member
Hi All Smile

FOLLOW UP #4:

To solve the "singleton" issue with org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl and to keep our 3.8.1 target platform I have chosen to rebuild our 3.8.1 target platform with a feature patch that patches the org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl class to allow for the presence of updated singleton plug-in's. Later when we upgrade to the 4.3 or 4.4 target platform this patch can then be abandoned.

[Updated on: Wed, 14 May 2014 14:44]

Report message to a moderator

Previous Topic:problems with headless self update
Next Topic:How do I create a category repository and then composite repository?
Goto Forum:
  


Current Time: Mon Jul 06 03:01:05 GMT 2015

Powered by FUDForum. Page generated in 0.01768 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software