[
https://issues.apache.org/jira/browse/SUREFIRE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Muff Diver updated SUREFIRE-1649:
---------------------------------
Description:
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 {{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*
[^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?
was:
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 {{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*
[^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?
> 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
> 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 {{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*
> [^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)
