Community
Participate
Working Groups
This is my understanding of how shared installs work: - user starts up Eclipse - can't write to the shared config area - we read the .eclipseproduct file at the root - use the product ID and version (and hash of the install dir) to create a local config folder for the user - e.g. ~/.eclipse/org.eclipse.platform_3.6.0_1655873425. - all user files are put here, including updates, installs, dropins, etc - then the root user updates the shared install - this process updates the version of the product in the .eclipseproduct file - user starts Eclipse - we create a local config area based on the algorithm above - area is new so we create it and go from there According to these steps, the user will not be able to retain any changes they made to the install while using the first version of the product. We need to review this and if the above statements are correct, figure out a good update story for users running a shared install and using the default generated configuration area.
Tom and I talked about this and wonder if going forward we can get rid of the app version from the calculation of the default user config area. This is our current formula: appName += File.separator + appId + "_" + appVersion + "_" + installDirHash; In the past we just used id + version but then we discovered problems if a product was installed multiple times (in different folders) on the same machine, so thus the addition of the install dir hash code. So we should investigate whether this is a good direction to go in: appName += File.separator + appId + "_" + installDirHash;
I thought there was some merging that happened between the update and the re-launch. Maybe this doesn't happen if the 'platform' is updated?
> So we should investigate whether this is a good direction to go in: > appName += File.separator + appId + "_" + installDirHash; This should suffice for the majority of the case. Two questions, what happens when the user specify a new configuration location? While we are modifying this do we want to add the ability in the .eclipseproduct file to specify the value for the "appName"?
(In reply to comment #3) > > So we should investigate whether this is a good direction to go in: > > appName += File.separator + appId + "_" + installDirHash; > This should suffice for the majority of the case. > Two questions, what happens when the user specify a new configuration location? The use of -configuration will cause that to be used instead of the computed one in <user.home>/.eclipse. That configuration will be cascaded over the configuration of the install area. So you would loose any configuration/profile data from the previously used configuration area in the user's home. > While we are modifying this do we want to add the ability in the > .eclipseproduct file to specify the value for the "appName"? Not sure if this is valuable. Isn't that pretty much the appId? I recommend we split this part of the bug into a new bug against the launcher and framework since that is where this default user configuration is calculated.
(In reply to comment #2) > I thought there was some merging that happened between the update and the > re-launch. Maybe this doesn't happen if the 'platform' is updated? > From my testing it doesn't seem to happen. Updating the .eclipseproduct file means that on next startup the launcher will calculate a new config location (which will be empty) and just use it. I've installed things as a user and then lost them after the root does an upgrade.
Move all 3.8 bugs to Juno.
Feel free to unschedule
*** Bug 163979 has been marked as a duplicate of this bug. ***
Created attachment 215755 [details] Change proposition Ok, this is the last time to fix that before Juno. Updating Eclipse happens pretty often (at least in Fedora), and each installation is a shared one. It would be really good to have consistent user.home location. Also, it would unblock the work on reinstalling user features after master configuration change (bug 304132, bug 358094).
Created attachment 215756 [details] mylyn/context/zip
(In reply to comment #9) > Created attachment 215755 [details] > Change proposition > > Ok, this is the last time to fix that before Juno. > > Updating Eclipse happens pretty often (at least in Fedora), and each > installation is a shared one. It would be really good to have consistent > user.home location. > > Also, it would unblock the work on reinstalling user features after master > configuration change (bug 304132, bug 358094). This is a bit risky at this point I think. Also I think you would need to change the code in the launcher as well in: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/tree/bundles/org.eclipse.equinox.launcher/src/org/eclipse/equinox/launcher/Main.java Around line 1346. This patch may be related to this bug, but I think you should open a separate bug against the framework for this change since this patch is against the framework and will also need a launcher change. DJ, we had discussed doing this in the past, but I do not remember why the version was included in the users default location.
Created attachment 224139 [details] Second part
I understand that a fix as suggested in comment #1 can help with finding the old profile, the dropins, or preserve preferences from the config scope. However I'm afraid that by removing this segment we are forcing a behavior (policy) onto people delivering Eclipse based products rather than just providing them with the mechanism to do what they want. For example, today I can decide whether or not I want an update from 3.8.0 to 3.8.1 to go in the same folder by controlling the version in the .eclipseproduct file. If I wanted to support an update for all the 3.x stream I would put just 3 in the version, and if I wanted to support any update I would not specify any version at all. So at this point, code wise, I think that the only work that needs to be done on the launcher code is to verify whether the absence of version in the .eclipseproduct file is supported and whether a specific shape is enforced for versions. Now that leaves us with the question of how we find the old profile? This will have to be handled by the migration logic and I can see many ways. For example , just thinking out loud, first we could look in the current configuration folder, then look in a folder starting with appId + version, then look for appId + partial version, etc... I think here the possibilities are rather limitless and again we should come up with decent defaults but let the user the possibility to control what happens.
I still don't get how to get an old location if the application version was just overwritten by the update. The only trace of the old platform may exist in profiles (but even that is not necessary, given that it is allowed to delete profiles). My opinion is that unless you explicitly track the history of product updates, you will not find the previous location. Not to mention that certain group of installers (rpm, IM and also many human users) do update by deleting the old installation and extracting a new image. No history there. Picking any "old" location in this case will be a wild guess (it will be based only on an app name - but there may be many locations with the same app since there could be many versions in the past). However, I do understand that RCP providers may want to control their location path strategy - which sounds more like a customization of existing code - I mean - maybe we should just let people toggle between both approaches, or even let them add their own strategies?
This has been addressed in Kepler by the addition of the migration wizard
