| Questions re. update sites for read-only/shared installs (might be repost, first time around :) ) [message #1278547] |
Thu, 27 March 2014 13:39  |
Christa Claesson
Messages: 5
Registered: March 2014 |
Junior Member |
|
|
Hi 
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
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 |
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03784 seconds
] 
Search
Help
Register
Login
Home
