[
https://issues.apache.org/jira/browse/SUREFIRE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793596#comment-16793596
]
Muff Diver commented on SUREFIRE-1649:
--------------------------------------
[~tibor17]? [~rfscholte]? Your thoughts, please?
> 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: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 3.0.0-M1, 3.0.0-M3, 2.22.0, 2.22.1, 3.0.0-M2
> 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
> Priority: Major
> Attachments: surefire.eg.zip
>
>
> The SureFire plugin's inability to apply {{additionalClasspathElements}}
> configs in Jigsaw projects, makes it inconvenient to comply with classpath
> scanning features of frameworks like JAX-RS.
> *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 does not 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 project's
> {{target/classes/}} folder to the {{test modulepath}}.
> *The Problem*
> 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_|^surefire.eg.zip] contains a JDK 11-based Maven project
> configured as described above. Running it through Maven (_with the included
> pom.xml_) will 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.
> *TL;DR*
> 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)
