Community
Participate
Working Groups
Build ID: 3.3M5 Steps To Reproduce: 1. Before calling EclipseLauncher.run(), create a set of Properties and try setting the property org.eclipse.core.runtime.adaptor.LocationManager.PROP_CONFIG_AREA to something like "@user.home/.myapp". 2. Supply this Property set to EclipseStarter.setInitialProperties(). 3. Call EclipseStarter.run( new String[0], null ). 4. Observe the call to mungeConfigurationLocation() from initializeLocations() in org.eclipse.core.runtime.adaptor. 5. Observe that the property specified as "@user.home/.myapp" has been prepended by "file://<current working directory>" by LocationHelper.buildURL() (on line 41 with the call to "new File(spec).toURL()"). 6. Observe that by the time mungeConfigurationLocation() returns and buildLocation() gets called on line 123, the osgi.configuration.area property is now a file-scheme URL, starting with the current working directory, followed by our original osgi.configuration.area property value, followed by a trailing slash. 7. Observe that buildLocation() thus fails to substitute the @user.home symbolic location at line 149, as our property value no longer begins with the symbolic location string, having been unintentionally prepended with the current working directory. More information: I reported this bug to the equinox-dev mailing list on 21 February 2007 with subject "Problem specifying osgi.config.area using symbolic location (@user.home)" with message ID <q944ppff4n0.fsf@chlorine.gnostech.com>, with the thread available here: http://thread.gmane.org/gmane.comp.ide.eclipse.equinox.devel/1381 As a possible fix, perhaps mungeConfigurationLocation() could be called after buildLocation() so that the location string is not prematurely forced to be a valid URL, allowing the symbolic locations to be expanded first.
See some related discussion in the comments for 108689, starting around comment #14: https://bugs.eclipse.org/bugs/show_bug.cgi?id=108689#c14
In step 4, I meant to mention the method org.eclipse.core.runtime.adaptor.LocationManager but neglected to include the class name.
That is, org.eclipse.core.runtime.adaptor.LocationManager.mungeConfigurationLocation() Third time's a charm.
Investigate fix/risk for M7.
Created attachment 63057 [details] patch This patch avoids calling buildURL in mungeConfigurationLocation. This is dead code I think. I don't know anyone who has ever launched Eclipse 3.0 or greater with -configuration someconfiguration/eclipse.cfg but the mungeConfigurationLocation seems to strip off the *.cfg in this case. There is no reason for calling buildURL here other than to convert '\' to '/' chars. There is also no need to add '/' to the end because that will be done later if needed.
Fix released to head. For completeness, the reason this is not failing when using the launcher (eclipse.exe and org.eclipse.equinox.launcher) is because the launcher processes the configuration option first and does the correct substitution before we enter the framework.
