Community
Participate
Working Groups
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.
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.
Carl, Konstantin, could you review this patch for 3.3.2?
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.
