Community
Participate
Working Groups
3.2 RC6 Sometimes, the dialog properties for editing Ant launch configuration properties will show that I have configured a specific JRE when I actually I had configured an execution environment. This seems to work every time: 1) on the JRE tab for an Ant external build launch config, make sure you have "Run in the same JRE as workspace" selected 2) close the dialog or switch to another launch config - when you reopen the same launch config, the setting is properly preserved 2) choose an execution environment (CDC-1.0/Foundation-1.0) 3) close the dialog or switch to another launch config - when you reopen the same launch config, the setting is *not* preserved. It will show instead the option "Separate JRE" selected, with the default JRE selected.
(In reply to comment #0) I can confirm this issue continues to occur in Eclipse 3.3 M4. It's quite annoying. I am trying to save a launch configuration for some projects and want to share them with other engineers through source control but the setting won't stick. If I change the JRE to an execution environment and move off the JRE tab and back, the setting stays. I can click 'Apply' and it will actually persist the correct configuration to a .launch file. But if I open it up again (or switch to another launch configuration and back), the setting gets wiped so if I save it again, it will not be the correct setting.
AntJRETab#initializeFrom, is erasing the jre container attribute and then asking for the default vminstall, which does not return an execution environment.
Created attachment 73576 [details] proposed fix the simplest fix is to persist and restore the JRE container path if it was present. That way after the removed deprecated vars and get default vm work is done we can simply put it back instead of persisting the temp state of the working copy (as it does now), resetting JRE settings.
*** Bug 196850 has been marked as a duplicate of this bug. ***
Created attachment 134659 [details] updated fix This updated patch resolves the use of deprecated attributes and the use of the JRE container attribute. This fix also resolves 137383.
*** Bug 137383 has been marked as a duplicate of this bug. ***
I guess that's for 3.6.
Created attachment 163007 [details] updated patch for 3.6M7 vs HEAD
applied patch to HEAD, please verify Darin W
The default JRE behavior seems to have changed when launch via "Run As > Ant Build". In 3.5.x, the default JRE was a separate VM. With this fix, the default JRE is now "Run in the same VM JRE as the workspace".
using the code from 3.6.x (prior to this patch) I can reproduce the default being "Same VM as workspace". Really the only other change that could have effected the setting was the launching split, where some of the constants were moved / renamed. Either way a regression has occurred.
Also though if you consider that the separate JRE option was being selected by mistake (the cause of the bug), then you could argue that the change to have the 'workspace VM' selected by default is indeed a fix and not a regression...
Marking fixed/verified. Will open a new bug for the regression.
Verified.
