maven-toolchains-plugin icon indicating copy to clipboard operation
maven-toolchains-plugin copied to clipboard

[MTOOLCHAINS-44] Use default JDK if it matches the request and no other toolchain is defined

Open jira-importer opened this issue 3 years ago • 3 comments

dennis lucero opened MTOOLCHAINS-44 and commented

Currently it is needed to have the toolchains defined in the toolchains.xml file. The Maven Docker images do not include a useful toolchains file. But since it’s possible to derive a usable toolchain from the system properties, it should not be required to store that information in the toolchains.xml file. Instead, Maven should check if the toolchain request could be fulfilled by the JDK running Maven.

I’m not sure if it’s reasonable to do this in all cases or only if the toolchains file does not contain any toolchain. For example, if the toolchains file only contains a Java 16 toolchain and the project requires Java 17 (exactly, not 17 or later) and Maven is run with Java 17, it would be possible to build the project (with Java 17), but probably not a good idea since it will fail when the Java installation Maven is running on is updated to version 18.


Affects: 3.1.0

jira-importer avatar Nov 15 '22 19:11 jira-importer

Elliotte Rusty Harold commented

My gut is that if a toolchain can't be located, we shouldn't simply use JAVA_HOME. Erroring is better here.

However, we might be able to define some defaults for certain JDK toolchains. The common case for toolchains is that the user wants a specific JDK version. If that's all they request, and toolchains.xml can't be found, or doesn't contain a matching JDK version, maven could still search in standard locations locally. For instance, suppose this is the configuration

{{ <configuration> <toolchains> <jdk> <version>1.8</version> </jdk> </toolchains> </configuration>}}

On a Mac you could run "/usr/libexec/java_home -V" to find a JDK that provides version 1.8.

jira-importer avatar Feb 25 '24 14:02 jira-importer

Elliotte Rusty Harold commented

The problem with this idea is that we can match JDK versions, but the configuration can have arbitrary other properties like vendor or willy_wonka. We have no way of matching anything else against the system installed libraries absent a toolchains.xml file.

That said, a jdk matched only by version is common enough that maybe we should special case that.

jira-importer avatar Mar 02 '24 13:03 jira-importer

dennis lucero commented

I noticed the toolchains plugin now has a JDK discovery mechanism. However it doesn’t work as I would expect after reading the documentation.

  • I don’t see any effect of {}<goal>select-jdk-toolchain</goal>{}. I thought it would set some internal state so the following <goal>toolchain</goal> would work, but that goal fails although mvn org.apache.maven.plugins:maven-toolchains-plugin:3.2.0:display-discovered-jdk-toolchains finds the JDK matching the required version in the toolchains plugin configuration section (using the maven:3-eclipse-temurin-17-alpine Docker image).
  • Running mvn org.apache.maven.plugins:maven-toolchains-plugin:3.2.0:generate-jdk-toolchains-xml generates ~/.m2/discovered-jdk-toolchains-cache.xml which does not seem to have any effect. However it works when renaming it to toolchains.xml.

jira-importer avatar Jan 23 '25 17:01 jira-importer