Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 147044

Summary:

[launching] external editor configuration dialog loses JRE setting

Product:

[Eclipse Project] Platform

Reporter:

Rafael Chaves <eclipse>

Component:

Ant

Assignee:

Michael Rennie <Michael_Rennie>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

darin.eclipse, eclipse, markus.kell.r, Michael_Rennie

Version:

3.2

Flags:

darin.eclipse: review+

Target Milestone:

3.6 M7

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
proposed fix	none
updated fix	none
updated patch for 3.6M7 vs HEAD	none

Description Rafael Chaves

2006-06-14 09:27:20 EDT

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.

Comment 1 David Hergert

2007-01-10 11:56:08 EST

(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.

Comment 2 Darin Swanson

2007-05-10 13:47:35 EDT

AntJRETab#initializeFrom, is erasing the jre container attribute and then asking for the default vminstall, which does not return an execution environment.

Comment 3 Michael Rennie

2007-07-11 14:14:44 EDT

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.

Comment 4 Michael Rennie

2007-07-17 13:51:22 EDT

*** Bug 196850 has been marked as a duplicate of this bug. ***

Comment 5 Michael Rennie

2009-05-06 13:55:09 EDT

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.

Comment 6 Michael Rennie

2009-05-06 13:55:54 EDT

*** Bug 137383 has been marked as a duplicate of this bug. ***

Comment 7 Markus Keller

2009-06-12 10:58:30 EDT

I guess that's for 3.6.

Comment 8 Michael Rennie

2010-03-25 11:54:20 EDT

Created attachment 163007 [details]
updated patch for 3.6M7 vs HEAD

Comment 9 Michael Rennie

2010-03-25 11:56:02 EDT

applied patch to HEAD, please verify Darin W

Comment 10 Darin Wright

2010-04-08 16:05:50 EDT

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".

Comment 11 Michael Rennie

2010-04-09 01:15:53 EDT

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.

Comment 12 Michael Rennie

2010-04-09 01:23:56 EDT

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...

Comment 13 Darin Wright

2010-04-09 09:57:42 EDT

Marking fixed/verified. Will open a new bug for the regression.

Comment 14 Darin Wright

2010-04-09 09:57:58 EDT

Verified.