Community
Participate
Working Groups
Build Identifier: I20110519-1138 When changing the target platform the ECLIPSE_HOME environment variable fails to update. This makes projects that depend on classpath settings to have errors until the workbench is restarted. Reproducible: Always Steps to Reproduce: 1. Open preferences, see value of ECLIPSE_HOME in Java/Build Path/Classpath Variables 2. Change the target platform to another eclipse installation 3. Repeat step #1 - The value you'll see is the same as before. However it should have updated to the new eclipse installation location. This was the behaviour in 3.4
I can't reproduce this bug when I tested between 3.7 and 3.8 M1. Could you please try with newer builds?
(In reply to comment #1) > I can't reproduce this bug when I tested between 3.7 and 3.8 M1. Could you > please try with newer builds? Here's the scenario: Eclipse SDK Version: 3.7.0 Build id: I20110613-1736 1. Started Eclipse, look at the Classpath variables (ECLIPSE_HOME) in preferences under Java/Build Path/Classpath Variables. 2) Look at the target platform (Preferences Plug-in Development/Target Platform), the directory matches what you see in ECLIPSE_HOME. 3) Change the target platform to point to a different eclipse installation. 4) Reinspect ECLIPSE_HOME. The value still points to the original value, it should have changed to use the target platform location from step #3. 5) Go back to the target platform setting and restore the target platform to its pre step 3 setting. 6) Reinspect ECLIPSE_HOME again. Now the value has updated to the value it would have had in step #3, however this is wrong, because the platform has been reset to a different value. In our code generation bundles we are referencing ECLIPSE_HOME for some of the Java dependencies to be set correctly. As you can see the value is not updated in sync with the setting of the target platform. Restarting eclipse after changing the target platform will yield a correct classpath.
Thanks for the detailed steps. I must have missed something in the previous attempt to reproduce this. Now I see what you mean. I will investigate.
The problem seem to be with the EclipseHomeInitializer, which for some reason uses the previous value of the target platform path while setting the ECLIPSE_HOME_VARIABLE. I am moving it to PDE.
Caused by an ordering problem. The preference where we store this information is getting modified after the classpath variable is asked to reset. Fix should be simple. The problem has existed since 3.6. We should consider backporting to 3.7.x.
Created attachment 201816 [details] Fix We are in the process of migrating to git and 3.7.1 RC2 is next week, so I am not sure when this will be backported. I am concerned that the ordering was done this way on purpose (certain preferences, including the platform path, are only set after the reset job runs). However, going through the operations on the reset job I don't see any reason why it should be called before all preferences are set. This fix moves the reload operation until the end of loadPlugins() call.
I didn't look at the patch but I agree (+1) that we should fix the problem for 3.7.1. On a side note: I would deprecate that variable and replace it with something less confusing like 'TARGET_PLATFORM_LOCATION'.
Ankur, can you please review this for 3.7.1? (In reply to comment #7) > On a side note: I would deprecate that variable and replace it with something > less confusing like 'TARGET_PLATFORM_LOCATION'. The deprecated variables still show up in the pref page right? I would think it would be confusing to see both variables there.
(In reply to comment #8) > Ankur, can you please review this for 3.7.1? > > (In reply to comment #7) > > On a side note: I would deprecate that variable and replace it with something > > less confusing like 'TARGET_PLATFORM_LOCATION'. > > The deprecated variables still show up in the pref page right? I would think it > would be confusing to see both variables there. Yes, but it will tell which variable to use instead.
Mike, if you have time today, please review so it gets included when tagging for RC2.
Looks good for MASTER and 3.7.1
Fixed in master and 3.7.1
Verified in M20110825-0847
This bug appears to come back in Eclipse Juno. The ordering fix made in LoadTargetDefininionJob was somehow lost in Juno. Steps to reproduce are the same.
It looks like the fix for bug 347695 destroyed/ignored some changes. When fixing this please also look for other possible destroyed fixes.
It looks like when the LoadTargetDefinitionJob was moved to the API package, the file wasn't up to date. http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?h=R3_8_maintenance&id=416bf2cb3b7375ac954afe12284a382d472eb5fe Fix for 3.8.2 The fix for master is ready to go, but waiting for Bug 319744 to be merged.
Fix in master: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=1f86f87582a26162cc76c3064ecc0f19dac77474
Verified in M20130116-1800
