You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Stanimir Stamenkov <s7...@netscape.net.INVALID> on 2022/08/06 18:07:07 UTC

Re: testCompile with multiReleaseOutput main classes

Sun, 31 Jul 2022 14:18:52 +0300, /Stanimir Stamenkov/:
> Sat, 23 Jul 2022 19:28:50 +0300, /Stanimir Stamenkov/:
>
>> I want to produce a Java 8 compatible library that provides some Java 
>> 9+ classes, packaged as a Multi-Release JAR:
>>
>>   * 
>> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html
>
> O.k.  From the very same page:
>
>> *Challenges*
>>
>>   * The Multi-Release: true attribute is only recognized when the 
>> classes are in a jar. In other words, you cannot test the classes put 
>> in target/classes/META-INF/versions/${release}/.
>
> I may try adding target/classes/META-INF/versions/${release}/ as a 
> test-resource directory using the build-helper-maven-plugin and see 
> how far I could get it.

All right. Not using build-helper-maven-plugin this time around, just 
the maven-compiler-plugin:

     <execution>
         <id>default-testCompile</id>
         <configuration>
             <compilerArgs>
                 <arg>-Xbootclasspath/a:${project.build.outputDirectory}/META-INF/versions/9</arg>
             </compilerArgs>
         </configuration>
     </execution>

and maven-surefire-plugin:

         <configuration>
             <additionalClasspathElements>
                 ${project.build.outputDirectory}/META-INF/versions/9
             </additionalClasspathElements>
         </configuration>

It is working fine so far [1].  Then I've noticed if I add to the 
configuration of the maven-compiler-plugin:

     <execution>
         <id>default-testCompile</id>
         <configuration>
             <source>9</source>
             <target>9</target>
             <compilerArgs>
                 <arg>-Xbootclasspath/a:${project.build.outputDirectory}/META-INF/versions/9</arg>
             </compilerArgs>
         </configuration>
     </execution>

the extra compiler arg stopped being effective, so I've though the 
compiler may have switched to a module path (vs. class path). So I've 
further tried:

     <execution>
         <id>default-testCompile</id>
         <configuration>
             <source>9</source>
             <target>9</target>
             <compilerArgs>
                 <arg>--patch-module</arg>
                 <arg>${module.name}=${project.build.outputDirectory}/META-INF/versions/9</arg>
             </compilerArgs>
         </configuration>
     </execution>

and then I've observed the following error:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile (default-testCompile) on project xbrz-core: Execution default-testCompile of goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile failed: Cannot invoke "java.util.Map.get(Object)" because the return value of "org.apache.maven.plugin.compiler.AbstractCompilerMojo.getPathElements()" is null -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.10.1:testCompile ...
...
Caused by: java.lang.NullPointerException: Cannot invoke "java.util.Map.get(Object)" because the return value of "org.apache.maven.plugin.compiler.AbstractCompilerMojo.getPathElements()" is null
	at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1126)
	at org.apache.maven.plugin.compiler.TestCompilerMojo.execute (TestCompilerMojo.java:183)
	...

that looks more like a bug in the compiler plugin itself.

[1] https://github.com/stanio/xbrz-java/commit/9e0fdf03c

-- 
Stanimir

Remove .INVALID from my address to reply directly to me, but it is possibly best to reply just to the list.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org