[jira] [Created] (SUREFIRE-1649) Allow Custom Configuration of The Standard Classpath in Jigsaw-based Projects

["Muff Diver (JIRA)" <ji...@apache.org>]

Muff Diver created SUREFIRE-1649:
------------------------------------

             Summary: Allow Custom Configuration of The Standard Classpath in Jigsaw-based Projects
                 Key: SUREFIRE-1649
                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1649
             Project: Maven Surefire
          Issue Type: Improvement
         Environment: *Java runtime*: OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
*OS*: Windows 7
*Maven*: v3.6.0
*SureFire Plugin*: v3.0.0-M3

            Reporter: Muff Diver
         Attachments: surefire.eg.zip

SureFire plugin's inability to apply additionalClasspathElements configs in Jigsaw projects, makes it inconvenient to comply with framework features like JAX-RS' classpath scanning.

*Steps to Reproduce*

_Prerequisite: JDK 11 Installed and set in {{JAVA_HOME}}_

1. Run the following Maven archetype command in a terminal:
{code:java}
mvn archetype:generate -DarchetypeArtifactId=jersey-quickstart-grizzly2 -DarchetypeGroupId=org.glassfish.jersey.archetypes -DinteractiveMode=false -DgroupId=eg.surefire.jdk11 -DartifactId=jersey.simple.service -Dpackage=eg.surefire.jdk11.jersey -DarchetypeVersion=2.28{code}
2. Run {{mvn test}} to establish that the newly-created project compiles and runs successfully

3. Add a {{module-info.java}} file to {{${basedir}/src/main/java/}}
 - add the appropriate {{requires}} and {{exports}} statements

4. Add a {{plugin}} block for the {{maven-surefire-plugin}} into the pom.xml
 - configure an {{additionalClasspathElements}} block for the plugin
 - add {{${basedir}/target/classes}} as the value

5. In a terminal, run {{mvn test}} again after editing pom.xml

*Expected Result*

1. The JAX-RS {{ResourceConfig}} component should have found the annotated {{MyResource}} implementation in the {{target/classes}} folder and initialized the service successfully
 2. The {{MyResourceTest}} should {{PASS}}

*Actual Result*

1. SureFire refuses to add the {{additionalClaspathElements}} to the classpath as configured 
 2. The {{ResourceConfig}} bean cannot find the annotated JAX-RS resource implementation because the {{target/classes}} folder was not included in the classpath
 3. The {{MyResourceTest}} fails with a {{404 Not Found}} because the JAX-RS-annotated {{MyResource}} implementation was not found; even though it is in fact located in {{target/classes}} — where it is expected to be

*Details*

When the SureFire plugin detects that it's running in a Jigsaw-based (JDK 9+) project, it constructs and uses a {{test modulepath}} in addition to a {{test classpath}}.

Under non-Jigsaw JDKs older than JDK 9, SureFire puts the project's {{target/classes}} folder in the standard classpath.

But running in a Jigsaw JDK, along with adding the {{target/test-classes}} folder to {{test modulepath}}, SureFire also adds the projects {{target/classes/}} folder to the {{modulepath}}.

The {{target/classes}} folder is not added to the classpath when SureFire's running a Jigsaw project.

The problem is that things like JAX-RS's {{ResourceConfig}} and the like — _things that scan the classpath for annotated implementations_ — can no longer find those annotated classes it expects to find in the standard classpath.

So if a test class exercises a JAX-RS-annotated resource implementation that is in a Jigsaw module, {{ResourceConfig}} is S.O.L. because SureFire has removed the annotated implementation from the standard classpath.

*Work-around*

The attached contains a JDK 11-based Maven project configured as described above. Running it through Maven (_with the included pom.xml_) should result in the unwanted {{404 Not Found}}.

I worked around SureFire's inability to add the additional classpath configuration, by configuring the maven-resource-plugin to copy the contents of {{target/classes}} to {{target/test-classes}}.

Running {{mvn -f lmx.mop test}} results in {{MyResourceTest}} successfully finding the {{MyResource}} class in {{target/test-classes}}. The test passes as a result.

That is the simplest way that I am aware of, at the moment, to get the annotated JAX-RS {{MyResource}} class into the classpath so that the test successfully finds it and passes.

It would be ideal to not have to resort to that kind of a hack.

Shouldn't it be possible to simply configure SureFire to acknowledge a developer-specified classpath?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)