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

Bug 370856

Summary:

On Java EE project creation the JRE class path entry is generated without the execution enviroment ID (e.g. "JavaSE-1.7").

Product:

[WebTools] WTP Common Tools

Reporter:

Dimo Stoilov <Dimo.Stoilov>

Component:

Faceted Project Framework

Assignee:

wst.common <wst.common-inbox>

Status:

RESOLVED INVALID

QA Contact:

Konstantin Komissarchik <konstantin>

Severity:

normal

Priority:

CC:

kaloyan

Version:

3.3.1

Flags:

konstantin: review-
kaloyan: review? (ccc)

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
proposed patch	none

Description Dimo Stoilov

2012-02-07 12:34:03 EST

This results in missing "Bundle-RequiredExecutionEnvironment" manifest header when installing OSGI bundle facet (Libra). This happens in case a runtime is chosen for the project. 

Details:
(1) in case you choose runtime you have not the execution enviroment ID:
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/jre7">
(2) in case you do not choose runtime (choose "none") you have it - "JavaSE-1.7":
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.7">

Impact - missing "Bundle-RequiredExecutionEnvironment" header:
When the project is migrated to plugin project. PDE searches for this ID in the JRE class path entry and sets its value for the "Bundle-RequiredExecutionEnvironment" header. However if such ID is not found like it is in (2) no Bundle-RequiredExecutionEnvironment header is set.

Comment 1 Dimo Stoilov

2012-02-07 12:54:08 EST

Created attachment 210670 [details]
proposed patch

The reason for the difference between (1) and (2) is: in (1) the JRE class path is set via the java facet delegate, and in (2) this is done by the org.eclipse.jst.common.project.facet.core.internal.StandardJreClasspathProvider in, and in a different way from the java facet delegate.

The proposed fix is in StandardJreClasspathProvider and sets the classpath entry in the same way like it is done in the java facet delegate.

Comment 2 Kaloyan Raev

2012-02-08 11:18:59 EST

Carl, Konstantin, could you review this patch for 3.3.2?

Comment 3 Konstantin Komissarchik

2012-02-09 11:52:25 EST

The difference in these two cases is intentional. When user targets a runtime, they are targeting a specific instance of a JVM (not just a particular version). When they don't target a specific runtime, we are free to apply a more generic specification based on facet version.

I would recommend pursuing a fix to PDE import procedure instead. There is no reason that their import couldn't be smarter and actually analyze the referenced JRE.