Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #168445 +++ CQ:WIND00254020 In bug 168445, a mechanism was added which disambiguates the auto-generated configuration area for read-only Eclipse installs by appending a hashcode of the installation directory. Unfortunately, this mechanism - doesn't work for installs that are physically writable - always uses the default "@user.home/.eclipse/*" pattern for the user's local configuration area. Many Eclipse-based products today use the "osgi.configuration.area" setting in config.ini in order to specify a custom location for their configuration, and thus run into the issue of multiple installations of the same product trampling on each other's configuration area. This is a request to make it possible and disambiguate such custom configuration locations by install dir hash as well, like with the default auto-generated location.
Created attachment 200287 [details] patch v1 Attached patch introduces a new placeholder ("@install.hash") which can be used in the context of specifying a configuration area or shared configuration area. Applying this to our product's config.ini looks like this and solves the problem of aliased configuration areas for us: osgi.configuration.area=@user.home/.workbench-3.3.2_@install.hash/configuration Please comment on feasibility of this approach and consider for inclusion in Eclipse. I assume that when the general approach is considered acceptable, o.e.osgi/LocationManager.java will have to be patched as well.
Personnally I simply install Eclipse in a separate directory created at the root of a local disk volume, e.g. in C:\Eclipse, and not in the Program Files or Windows folder. This avoids the problem caused by virtualization (which protects the shared storage space), and still allows me to share the installation across users (but then they won't have user-specific plugins : the configuration area is the same for every user). This also means that only one user can use that installation at any time. If you want more users, each one has to have his separate installation of Eclipse (this is generally the case, each one has his own PC), and each one much manage its software updates himself. Anyway, this is not really different with other large IDE (including Visual Studio).
The difference between Eclipse and "other large IDE's" is that Eclipse may just be a component embedded into many different products. Thus there's a need for products to configure Eclipse to match their requirements. If you can live with installing into the root, that's fine ... in our product this would cause issues so we'd rather explicitly redirect the config area but avoid aliasing installations.
Thanks Martin, I will review today and possibly include in M1, but this likely will slip into M2.
Thanks Tom! One thing I was not quite sure about, was the syntax to use for the placeholder ... I'm using the "@install.hash" syntax for now since it's consistent with other placeholders but I'm open for other suggestions.
This will have to wait for M2.
I'd appreciate comments / review of the attached patch, Juno M2 is scheduled for Sep 16 according to the calendar...
A similar patch will be needed to org.eclipse.core.runtime.adaptor.LocationManager in the framework. In the patch you do a check for the indexOf "install.hash" for the location string and substitute the install hash if (idx > 0). Is there a reason you don't support placement of @install.hash at the beginning of the location string? (In reply to comment #3) > The difference between Eclipse and "other large IDE's" is that Eclipse may just > be a component embedded into many different products. Thus there's a need for > products to configure Eclipse to match their requirements. I am confused by this requirement since I imagine your products configure the osgi.configuration.area property themselves. Is there a reason they are not supplying the unique value needed there instead of depending on the platform to substitute some unique value?
Created attachment 202943 [details] updated patch Here is an updated patch that included changes to LocationManager. I also changed the check to allow @install.hash to be at the beginning of a location string.
Thanks for applying the fix to LocationManager - I just didn't want to make that effort before getting consensus on the approach. Allowing @install.hash at the beginning of the String just didn't occur to me because the code is only dealing with absolute paths so far - putting the hash at the beginning creates a relative path which doesn't seem very meaningful. Have you tested whether the relative path is accepted as valid URL? Is it created under the current directory, or anywhere else? (In reply to comment #8) > > The difference between Eclipse and "other large IDE's" is that Eclipse may > > just be a component embedded into many different products. Thus there's a > > need for products to configure Eclipse to match their requirements. Reading this statement again, I see how the word "embedded into products" is confusing... in fact our product uses the stock Eclipse Launcher, but for years we have documented the specific location of the config area under the user home and we can't make the install area read-only to leverage the current launcher's capability (on Windows I wouldn't know how to force it read-only since that's not supported by the file attributes). Those constraints come by shipping Eclipse as part of our other product... "embedded" is perhaps not the right term here.
(In reply to comment #10) > Thanks for applying the fix to LocationManager - I just didn't want to make > that effort before getting consensus on the approach. > > Allowing @install.hash at the beginning of the String just didn't occur to me > because the code is only dealing with absolute paths so far - putting the hash > at the beginning creates a relative path which doesn't seem very meaningful. > Have you tested whether the relative path is accepted as valid URL? Is it > created under the current directory, or anywhere else? Good point, I did not think of what it would mean to put the hash at the beginning and the result being a relative location. The relative location would likely end up being relative to the current working directory which is random and not usually the expected location. I think I may throw a RuntimeException if idx==0 in that case just to make it clear that placing @install.hash at the beginning is not allowed. > > (In reply to comment #8) > > > The difference between Eclipse and "other large IDE's" is that Eclipse may > > > just be a component embedded into many different products. Thus there's a > > > need for products to configure Eclipse to match their requirements. > > Reading this statement again, I see how the word "embedded into products" is > confusing... in fact our product uses the stock Eclipse Launcher, but for years > we have documented the specific location of the config area under the user home > and we can't make the install area read-only to leverage the current launcher's > capability (on Windows I wouldn't know how to force it read-only since that's > not supported by the file attributes). > > Those constraints come by shipping Eclipse as part of our other product... > "embedded" is perhaps not the right term here. I actually was not focused on the use of "embedded" in my confusion :-) Here is a scenario that I imagine, let me know if it is accurate: 1) You have a product based on eclipse installed in /Program Files/MyAppV1/ 2) This product has a configuration that sets osgi.configuration.area=@user.home/MyApp/configuration/ 3) You have another version of the product installed in /Program Files/MyAppV2/ 4) This product also has a configuration that sets osgi.configuration.area=@user.home/MyApp/configuration/ So now you have to versions of your product attempting to use the same osgi.configuration.area. The obviously results in collisions between the two products. Your solution is to allow the osgi.configuration.area setting to have an option to substitute the install.hash value into the configuration location. While I understand the solution, I am still unclear why MyAppV2 simply did not set the osgi.configuration.area=@user.home/MyAppV2/configuration/ instead so it would not collide with the MyAppV1 configuration area.
(In reply to comment #11) > While I understand the solution, I am still unclear why MyAppV2 > simply did not set the > osgi.configuration.area=@user.home/MyAppV2/configuration/ instead so it would > not collide with the MyAppV1 configuration area. I think I may know the answer myself. Is it because your product may get provisioned to an already installed eclipse and this product could be installed across multiple installations of eclipse on the same machine? If the same product version was installed on multiple installation of eclipse you would end up with multiple installations of eclipse trying to use the same configuration area, which would be bad.
I released the fix with commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=9a365c23db3abf8409d7c09a8973e514ab11437d Notice that I decided to throw a runtime exception if @install.hash is at the beginning of the location. Also notice that I decided to increase the launcher version to 1.3 since we are adding new functionality. This resulted in needing to update the host ranges of all the launcher fragments and also the versions of all the fragments have increased.
.
(In reply to comment #12) > > While I understand the solution, I am still unclear why MyAppV2 > > simply did not set the > > osgi.configuration.area=@user.home/MyAppV2/configuration/ instead The main reason is that we ship our product (Workbench) in different configurations for different target platforms, where "configuration" is data-driven outside Eclipse (eg compiler versions, debugger DLL's etc). It's exactly the same Core Eclipse but with different sets of plugins / enablers / compilers etc. Exmple: /MyAppV2/WBForVxworks69 /MyAppV2/WBForWrlinux42 /MyAppV2/WBForWrlinux41 all of these products would contain the same Eclipse Core (exactly same bits) but in different configs, so we must ensure that the configuration areas don't clash. Products can also be a mix-and-match-of components, or users can add more components after the fact (eg Add Vxworks69 to the Wrlinux41 install) so we cannot code the product variant into config.ini. There's also 2 other scenarios: - Directory aliasing, eg launching from \\server\share\MyAppV2 or D:\MyAppV2 fails since 1st launch generates a config area invalid for the 2nd one - Physically moving an install from D:\MyAppV2 to E:\MyAppV2 We better re-generate the config area in these cases, the roaming profile only works when it's physically stored inside the moved product (which we can't do easily for other reasons), but not when it's redirected to the userhome. Thanks again for accepting the patch :)
I'm really glad that this could be fixed since it resolves the "configuration area aliasing" problem which had been reported by multiple incidents. CQ:WIND00221233 CQ:WIND00240566 CQ:WIND00227803
CQ:WIND00252460
CQ:WIND00023389
