M2E wrongly uses enforcer requireJavaVersion to configure projects

[Bananeweizen]

Since eclipse-tycho/tycho#1740 all the classpaths in Tycho use Java 17 on my machine. That's clearly wrong, at least these 2 projects had other settings before (and they use specific other source/target values in their POMs):

I have Java 8, 11, 17 in my workspace preferences and I have all necessary EE levels mapped in the workspace preferences.

[HannesWell]

This is a bit strange. IIRC the StandardVMType/-classpath entries for those projects were the same when I tested it.
But now it is java-17 for me as well.

I hope this isn't another regression from #981.
Will look into this in the next days.

The relevant class is probably AbstractJavaProjectConfigurator:

m2e-core/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/AbstractJavaProjectConfigurator.java

Lines 173 to 176 in 50a9dc9

	String executionEnvironmentId = getExecutionEnvironmentId(options);
	String buildEnvironmentId = getMinimumJavaBuildEnvironmentId(request, monitor);
	addJREClasspathContainer(classpath, buildEnvironmentId != null ? buildEnvironmentId : executionEnvironmentId);

[HannesWell]

While analyzing the problem I noticed that Tycho in general and therefore the projects you mentioned have a maven-enforcer-plugin execution with a requireJavaVersion rule configured:

https://github.com/eclipse-tycho/tycho/blob/3098bd215d5be0b8b00cd3e87bc35f4d1463d5be/pom.xml#L446-L448

Since in the properties section <min.jdk.version>17</min.jdk.version> is configured the build has to be performed with Java-17 and therefore I think M2E does everything right when it sets the JRE_CONTAINER to Java-17.
Please add your remarks to #842 (comment), if you think this is a false assumption.

[Bananeweizen]

To my understanding the requireJavaVersion rule is meant to clarify the version of the JVM that Maven itself runs on. It does not say anything about the source, target or other compiler/testing/runtime related Java levels of the modules being worked on.
See https://github.com/apache/maven-enforcer/blob/master/enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireJavaVersion.java
Since Maven maps the compiler source/target level for each module via toolchains and then uses the matching JRE, m2e should not set any other level. Not in the prefs and not in the classpath. It will work (if at least the prefs are at the right level), but it's absolutely not recommended to have a wrong JRE version on the classpath. That's why the warning from JDT is shown in the first place. Also it's not even necessary that m2e tries to be more clever than JDT there. If m2e finds a compiler source setting of 13 in the POM, and I don't have any JRE matching 13, then it should still set the prefs and classpath to 13. In Eclipse I will later select another installed JRE (like 17) to be mapped in the Java > Execution Environments preferences, and everything will be fine.

[kwin]

It does not say anything about the source, target or other compiler/testing/runtime related Java levels of the modules being worked on.

Neither does the underlying JRE Library do that, that is configured separately in the Eclipse JDT Compiler settings.

The reason why m-e-p configuration is evaluated is that the project's JRE Library is also used for running Maven from Eclipse by default (

m2e-core/org.eclipse.m2e.launching/src/org/eclipse/m2e/actions/ExecutePomAction.java

Line 249 in ad43099

private IPath getJREContainerPath(IContainer basedir) throws CoreException {

and

m2e-core/org.eclipse.m2e.launching/src/org/eclipse/m2e/actions/ExecutePomAction.java

Line 221 in ad43099

workingCopy.setAttribute(IJavaLaunchConfigurationConstants.ATTR_JRE_CONTAINER_PATH, path.toPortableString());

) and would therefore fail if any of the Maven plugins require a newer JRE.

I agree that on the long term it would be good if m2e would establish a separate configuration for the JVM used to run Maven (but currently this is the project's JRE system library).