Stephen Colebourne commented on SUREFIRE-1497:

 The goal of the issue is to match how the library will be used. It might be 
used on the modulepath or it might be used on the classpath. There is no way 
that I as library author can control which approach the end-user will use. As 
such, I need a way to test the library in both ways.

Today, I changed the surefire version from v2.20.1 to v2.21.0. This found two 
separate cases where the module I had setup was incorrect. Now that it is setup 
correctly, surefire v2.21.0 tests this. However, in order to know whether the 
code still works on the classpath, the only option surefire has at present is 
to temporarily downgrade the version and re-run the tests.

This is not theoretical either. To use ServiceLoader in Java 9 you have to 
duplicate the configuration. Once in META-INF/services and once in 
module-info.java. As it stands, there is no way in v2.21.0 to test the 
META-INF/services config, as that config is only used when the module is on the 

A test case exposing this would be a module where META-INF/services is missing 
or wrong, but the module-info.java provides clause is correct.

> Flag to select modulepath or classpath
> --------------------------------------
>                 Key: SUREFIRE-1497
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1497
>             Project: Maven Surefire
>          Issue Type: Improvement
>    Affects Versions: 2.21.0
>            Reporter: Stephen Colebourne
>            Priority: Major
> SUREFIRE-1262 added the ability to run tests using the modulepath, which is 
> great. However, as a library developer I cannot guarantee that the code will 
> be run on the modulepath, it might well be run on the classpath.
> As such, can I request a flag that turns the behaviour in SUREFIRE-1262 on 
> and off? This would allow a single pom.xml to run surefire twice, once with 
> the code on the modulepath and once with the code on the classpath, to ensure 
> that the behaviour always works however the code is run. (Other solutions to 
> achieve the same goal may be possible, but this seems the most obvious).

This message was sent by Atlassian JIRA

Reply via email to