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)
