You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Muff Diver (JIRA)" <ji...@apache.org> on 2019/03/15 04:47:00 UTC
[jira] [Updated] (SUREFIRE-1649) Allow Custom Configuration of The
Standard Classpath in Jigsaw-based Projects
[ https://issues.apache.org/jira/browse/SUREFIRE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Muff Diver updated SUREFIRE-1649:
---------------------------------
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
was:
*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
Description:
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 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 {{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?
was:
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?
> 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
>
>
> 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 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 {{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)