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

Bug 298712

Summary:	Java Facet should utilize Execution Environment when updating Java Build Path
Product:	[WebTools] WTP Common Tools	Reporter:	Nitin Dahyabhai <thatnitind>
Component:	Faceted Project Framework	Assignee:	Konstantin Komissarchik <konstantin>
Status:	RESOLVED FIXED	QA Contact:	Konstantin Komissarchik <konstantin>
Severity:	enhancement
Priority:	P3	CC:	cbridgha, jsholl, robert_gallagher
Version:	3.1	Keywords:	plan
Target Milestone:	3.2 M5
Hardware:	All
OS:	All
Whiteboard:

Description Nitin Dahyabhai

2010-01-02 22:30:22 EST

Since we're having the user pick a JRE level when setting the Facet instead of a specific JRE, it would be better if the changes to the Build Path used the corresponding Execution Environment, letting JDT pick the matching JRE itself at build time.

Comment 1 Chuck Bridgham

2010-01-04 10:53:22 EST

Moving over to facet framework

Comment 2 Chuck Bridgham

2010-01-04 10:55:58 EST

I'm ok with this if the project doesn't have a server target with a specific jre installed.  Shouldn't we always use the server specified jre if available?

Comment 3 Konstantin Komissarchik

2010-01-04 16:45:32 EST

Chuck is correct. This proposed behavior does make sense in the "no runtime" case, but not when the project targets a specific runtime. Currently the user can only point to a specific named runtime, so all project metadata must reference that one runtime.

In order to fully utilize JDT Execution Environments, we would have to create our own parallel concept of an execution environment, something that I thought about in the past but haven't had the time to follow through. 

I will use this enhancement request to track changing the "no runtime" case. The current behavior in the no runtime case is to reference the workspace default JRE. Referencing an execution environment would be better in that case.

Comment 4 Nitin Dahyabhai

2010-01-04 20:42:33 EST

(In reply to comment #3)
> Chuck is correct. This proposed behavior does make sense in the "no runtime"
> case, but not when the project targets a specific runtime. Currently the user
> can only point to a specific named runtime, so all project metadata must
> reference that one runtime.

I can see distinct containers for the JRE and app server on my Java Build Path, and wouldn't think of them as being tied together without having read this.

Comment 5 Konstantin Komissarchik

2010-01-13 12:16:58 EST

Released changes to 3.2 M5 stream and fproj.