Don't rely on Maven's toolchains.xml when providing custom JDKs locations

[pivovarit]

For now, in order to provide custom JDKs, we need to first add them to Maven toolchains.xml, then extract corresponding JAVA_HOMEs using a Groovy script, only to add them to build properties.

I'm not sure if there's some deeper context behind it being done this way, but it looks like it could be easily simplified just by supplying the build with JAVA_HOMEs directly:

RUN mvn install -DjavaHome1=FOO -DjavaHome2=FOO

I have a PoC ready that was made alongside https://github.com/AdoptOpenJDK/jdk-api-diff/pull/9

You can see the diff here: https://github.com/pivovarit/jdk-api-diff/commit/e95160b52b3bdd21f72e60bbc0be1173ea308095

[gunnarmorling]

I'm not sure if there's some deeper context behind it being done this way

The context is to provide some means of abstraction and portability. Instead of hard-coding JDK paths in the pom.xml, one would give the "requirements" (i.e. version, platform etc.) and the matching installations would be returned by the toolchains mechanism. As you say it's a bit of a moot point when passing these options via properties, it'd only mean that an mvn clean package without any properties wouldn't run any longer. I'm open to it, if it's properly documented and a clear error message is given if no properties are passed.

[pivovarit]

One way or the other - maven clean package requires some set of parameters to work properly. So, if someone doesn't have a valid toolchains.xml setup - mvn clean package doesn't run as well - so it's those two setups are equal in this field.

I'm speaking from my experience as the first-time user of the tool - it was quite tedious for me to need to set up my Maven's toolchains.xml to be able to generate a report.

On a daily basis, I use tools that allow me to not couple myself to a particular build tool, so juggling JAVA_HOMEs with SDKMAN feels much more natural, but I believe the Docker-based solution would be an ultimate one since it requires a minimalistic setup from a user perspective: https://github.com/AdoptOpenJDK/jdk-api-diff/pull/9

[karianna]

@gunnarmorling is there a sample set of toolchain files that you can recommend here? GitHub actions is also failing to build this project.

[gunnarmorling]

There's an example in the README: https://github.com/AdoptOpenJDK/jdk-api-diff#usage. But I'm definitely open for alternatives. Tbh. I forgot about this PR, so don't remember from the top of my head how @pivovarit's approach would look like.

[pivovarit]

My approach was to encapsulate the whole process in a Docker container and just feed names of JDKs to it