Mailing-List: contact issues-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@maven.apache.org
Date: Fri, 22 Sep 2017 09:59:00 +0000 (UTC)
From: "Gunnar Morling (JIRA)" <jira@apache.org>
To: issues@maven.apache.org
Message-ID: <JIRA.13104242.1506074207000.174943.1506074340351@Atlassian.JIRA>
In-Reply-To: <JIRA.13104242.1506074207000@Atlassian.JIRA>
References: <JIRA.13104242.1506074207000@Atlassian.JIRA> <JIRA.13104242.1506074207253@jira-lw-us.apache.org>
Subject: [jira] [Updated] (SUREFIRE-1420) Support running unit tests in
 named Java 9 modules
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 22 Sep 2017 09:59:07 -0000


     [ https://issues.apache.org/jira/browse/SUREFIRE-1420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gunnar Morling updated SUREFIRE-1420:
-------------------------------------
    Description: 
As far as I can tell, Surefire will run tests using the traditional classpath also on Java 9. When the project that is built is a named Java 9 module (i.e. it contains a module descriptor), it'd be desirable to have a way to run the tests using the module path instead.

For that, the following things would be required:

* Adding the currently built project and its dependencies to the module path instead of the class path when forking the java process running the tests
* Adding a read edge from the currently built module to the used testing library, e.g. JUnit, if it's not present as a dependence in the module descriptor already (which it usually won't)
* Patching the classes from _target/test-classes_ into the currently built module (as represented by the classes under _target/classes_)
* Opening up packages containing tests to the testing library so they can be accessed reflectively

I could perform these steps manually by applying the following configuration for the Surefire plug-in:

{code}
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.20.1</version>
    <configuration>
        <!-- Don't add any dependencies to the class path -->
        <classpathDependencyScopeExclude>test</classpathDependencyScopeExclude>

        <argLine>--module-path=target/classes:/path/to/junit/junit/4.12/junit-4.12.jar:
                               /path/to/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
                 --add-modules com.example,junit,hamcrest.core
                 --add-reads com.example=junit
                 --add-opens com.example/com.example.internal=junit
                 --patch-module com.example=target/test-classes</argLine>
        
        <!-- Prevents target/classes to be added to the classpath -->                
        <classesDirectory>path/to/none</classesDirectory>

        <!-- Doing the same for test classes failed as it caused no tests to be found; it still works, 
              I assume the --patch-module above takes precedence over their occurrence on the classpath -->
        <!-- <testClassesDirectory>path/to/none</testClassesDirectory> -->
    </configuration>
</plugin>
{code}

Ideally, an equivalent {{java}} invocation would be done by Surefire automatically when building a named module.

  was:
As far as I can tell, Surefire will run tests using the traditional classpath also on Java 9. When the project that is built is a named Java 9 module (i.e. it contains a module descriptor), it'd be desirable to have a way to run the tests using the module path instead.

For that, the following things would be required:

* Adding the currently built project and its dependencies to the module path instead of the class path when forking the java process running the tests
* Adding a read edge from the currently built module to the used testing library, e.g. JUnit, if it's not present as a dependence in the module descriptor already (which it usually won't)
* Patching the classes from _target/test-classes_ into the currently built module (as represented by the classes under _target/classes_)
* Opening up packages containing tests to the testing library so they can be accessed reflectively

I could perform these steps manually by applying the following configuration for the Surefire plug-in:

{code}
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.20.1</version>
    <configuration>
        <!-- Don't add any dependencies to the class path -->
        <classpathDependencyScopeExclude>test</classpathDependencyScopeExclude>

        <argLine>--module-path=target/classes:/path/to/junit/junit/4.12/junit-4.12.jar:
                                 /path/to/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
                 --add-modules com.example,junit,hamcrest.core
                 --add-reads com.example=junit
                 --add-opens com.example/com.example.internal=junit
                 --patch-module com.example=target/test-classes</argLine>
        
        <!-- Prevents target/classes to be added to the classpath -->                
        <classesDirectory>path/to/none</classesDirectory>

        <!-- Doing the same for test classes failed as it caused no tests to be found; it still works, 
              I assume the --patch-module above takes precedence over their occurrence on the classpath -->
        <!-- <testClassesDirectory>path/to/none</testClassesDirectory> -->
    </configuration>
</plugin>
{code}

Ideally, an equivalent {{java}} invocation would be done by Surefire automatically when building a named module.


> Support running unit tests in named Java 9 modules
> --------------------------------------------------
>
>                 Key: SUREFIRE-1420
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1420
>             Project: Maven Surefire
>          Issue Type: New Feature
>            Reporter: Gunnar Morling
>
> As far as I can tell, Surefire will run tests using the traditional classpath also on Java 9. When the project that is built is a named Java 9 module (i.e. it contains a module descriptor), it'd be desirable to have a way to run the tests using the module path instead.
> For that, the following things would be required:
> * Adding the currently built project and its dependencies to the module path instead of the class path when forking the java process running the tests
> * Adding a read edge from the currently built module to the used testing library, e.g. JUnit, if it's not present as a dependence in the module descriptor already (which it usually won't)
> * Patching the classes from _target/test-classes_ into the currently built module (as represented by the classes under _target/classes_)
> * Opening up packages containing tests to the testing library so they can be accessed reflectively
> I could perform these steps manually by applying the following configuration for the Surefire plug-in:
> {code}
> <plugin>
>     <groupId>org.apache.maven.plugins</groupId>
>     <artifactId>maven-surefire-plugin</artifactId>
>     <version>2.20.1</version>
>     <configuration>
>         <!-- Don't add any dependencies to the class path -->
>         <classpathDependencyScopeExclude>test</classpathDependencyScopeExclude>
>         <argLine>--module-path=target/classes:/path/to/junit/junit/4.12/junit-4.12.jar:
>                                /path/to/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
>                  --add-modules com.example,junit,hamcrest.core
>                  --add-reads com.example=junit
>                  --add-opens com.example/com.example.internal=junit
>                  --patch-module com.example=target/test-classes</argLine>
>         
>         <!-- Prevents target/classes to be added to the classpath -->                
>         <classesDirectory>path/to/none</classesDirectory>
>         <!-- Doing the same for test classes failed as it caused no tests to be found; it still works, 
>               I assume the --patch-module above takes precedence over their occurrence on the classpath -->
>         <!-- <testClassesDirectory>path/to/none</testClassesDirectory> -->
>     </configuration>
> </plugin>
> {code}
> Ideally, an equivalent {{java}} invocation would be done by Surefire automatically when building a named module.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)