Hello Polarian
The <maven.compiler.release> and <maven.compiler.testRelease> properties
do not specify which JDK to use. By default, Maven always uses the
compiler provided with the Java release on which Maven is running, and
the above properties only specify the values to give to the
--release option. For checking on which Java release Maven is running,
execute `mvn --version` on the command line. If a different JDK is
desired for the compilation and the tests, toolchain can be used. But it
may be easier to just set the JAVA_HOME environment variable to the path
to the desired JDK before to run Maven.
Martin
Le 21/10/2025 à 21:03, Polarian a écrit :
Good evening,
First time posting to this list so apologises for any potential
mistakes.
While packaging Java software, I kept getting frustrated at tests
failing preventing builds. Maven by default will run the test goal when
you package.
To allow the distro packaging method to dictate whether to skip the
tests or not, I decided to skip tests when building and then run them
explicitly within the distro's test phase, this allows tests to be
skipped when building the distro package.
However I ran into a problem. It occurs sometimes that multiple jdk's
are pulled into the same build environment, and usually the newest is
the default, but for some software they have a minimum AND maximum JDK
version, this causes the build to fail.
So adding the following to properties I would assume fixes the
problem: (could also be added to the plugin configuration)
<maven.compiler.release>17</maven.compiler.release>
<maven.compiler.testRelease>17</maven.compiler.testRelease>
This works when packaging the software, Java 17 is automatically
detected and used, however for tests, the latest JDK is still used.
Now I am not sure if this is because of surefire or not. But surefire
states under <jdkToolchain>:
Allow for configuration of the test jvm via maven toolchains. This
permits a configuration where the project is built with one jvm and
tested with another. This is similar to jvm, but avoids hardcoding
paths.
and then <jdk>
Option to specify the jvm (or path to the java executable) to use
with the forking options. For the default, the jvm will be a new
instance of the same VM as the one used to run Maven
So surely if it is inherited from maven, <testRelease> should be
dictating the JDK version used?
In any case, for now I had to hard code JAVA_HOME to get the test to
use the right JDK, but this is bad for packaging as you would need to
change multiple places.
If there is a better way to ensure that a specific JDK is used to run
tests within the pom.xml please let me know. Would make maintaining the
package a lot easier when PR'd upstream for them to update themself
(currently they just tell you the required JDK version, if the pom
explicitly specifies it, it takes the headache out of packaging).
Thanks,
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
