somehow projects are loosing their set ExecutionEnvironment in the classpath file.
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-11">
turns into
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER">
This happens when i trigger Maven -> Update Project... (Eclipse context menu on project) or "Import as Maven Project" when i check it out from git.
This can be reproduced with the Tycho demo bundle tycho.demo.itp01. Just checkout the git and import the project in eclipse. (Import -> Existing Maven Porjects). With the Manifest file you can reset the ExecutionEnvironment to the expected value and then trigger a Maven Update Project.
I tried to debug it a little. In the TychoLifecycleMapping.addJavaProjectOptions function the classpath is added with the correct information, but the option-map is not filled. The calling function in AbstractJavaProjectConfigurator.configure then continues, tries to resolve an ExecutionEnvironment, that it can not find due to the empty map and then adds the default JRE_CONTAINER entry without ExecutionEnvironment.
So my question would be if the TychoLifecycleMapping.addJavaProjectOptions function can continue to call its super function even if it sets the classpath on their own already, move it out of the else block here:
Hi everyone,
somehow projects are loosing their set ExecutionEnvironment in the classpath file.
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-11">
turns into<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER">
This happens when i trigger Maven -> Update Project... (Eclipse context menu on project) or "Import as Maven Project" when i check it out from git.
This can be reproduced with the Tycho demo bundle tycho.demo.itp01. Just checkout the git and import the project in eclipse. (Import -> Existing Maven Porjects). With the Manifest file you can reset the ExecutionEnvironment to the expected value and then trigger a Maven Update Project.
I tried to debug it a little. In the TychoLifecycleMapping.addJavaProjectOptions function the classpath is added with the correct information, but the option-map is not filled. The calling function in AbstractJavaProjectConfigurator.configure then continues, tries to resolve an ExecutionEnvironment, that it can not find due to the empty map and then adds the default JRE_CONTAINER entry without ExecutionEnvironment.
So my question would be if the TychoLifecycleMapping.addJavaProjectOptions function can continue to call its super function even if it sets the classpath on their own already, move it out of the else block here: