Re: Maven Compiler Plugin: Not respecting testRelease flag?

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,