[ 
https://issues.apache.org/jira/browse/SUREFIRE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097465#comment-17097465
 ] 

Gili edited comment on SUREFIRE-1563 at 5/1/20, 3:54 PM:
---------------------------------------------------------

[~rfscholte] Assuming I understand you correctly, I believe we have the same 
requirements. So let me throw the following proposal on the table:

Use-cases:

1. Blackbox testing: 
* Users are expected to provide {{src/test/java/module-info.java}} which 
"requires" the main module.
* Maven compiles this as-is (No merging against the main {{module-info) }}into 
target/test-classes.
* Surefire uses this {{module-info}} without modification. 

2. Whitebox testing: 
* Option A: Users provide {{src/test/java/module-info.java}} which works like 
the blackbox testing case, then use the SharedSecrets mechanism 
(https://stackoverflow.com/a/53653651/14731) with qualified exports to access 
internal members. 
* Option B: Users provide {{src/test/java/module-info.java}}, and specify in 
{{pom.xml}} that tests are meant to do whitebox testing. Surefire executes with 
module-info that is a join between the main and test module-info files.

3. requires static case:
* To Stephen's point: Is Maven/Surefire able to find "requires static" in 
{{module-info.java}} and automatically fire off the desired command-line 
options on behalf of the user? Does the user need to specify anything for 
correct execution or do we have sufficient information?

I prefer Option 2A but I appreciate that it involves a lot more work for users 
than Option 2B. I'm open to new ideas as well.

So, which points do we all agree on (so we can take them off the table) before 
moving on to the points of contention?


was (Author: cowwoc):
[~rfscholte] Assuming I understand you correctly, I believe we have the same 
requirements. So let me throw the following proposal on the table:

Use-cases:
 # Blackbox testing: 
* Users are expected to provide {{src/test/java/module-info.java}} which 
"requires" the main module.
* Maven compiles this as-is (No merging against the main {{module-info) }}into 
target/test-classes.
* Surefire uses this {{module-info}} without modification. 
 # Whitebox testing: 
* Option A: Users provide {{src/test/java/module-info.java}} which works like 
the blackbox testing case, then use the SharedSecrets mechanism 
(https://stackoverflow.com/a/53653651/14731) with qualified exports to access 
internal members. 
* Option B: Users provide {{src/test/java/module-info.java}}, and specify in 
{{pom.xml}} that tests are meant to do whitebox testing. Surefire executes with 
module-info that is a join between the main and test module-info files.
 # requires static case:
* To Stephen's point: Is Maven/Surefire able to find "requires static" in 
{{module-info.java}} and automatically fire off the desired command-line 
options on behalf of the user? Does the user need to specify anything for 
correct execution or do we have sufficient information?

I prefer Option 2A but I appreciate that it involves a lot more work for users 
than Option 2B. I'm open to new ideas as well.

So, which points do we all agree on (so we can take them off the table) before 
moving on to the points of contention?

> NoClassDefFoundError for JPMS modules with "require static"
> -----------------------------------------------------------
>
>                 Key: SUREFIRE-1563
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1563
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.22.0
>            Reporter: Simone Bordet
>            Assignee: Olivier Lamy
>            Priority: Major
>         Attachments: maven-jpms.tgz
>
>
> When a Maven module has a {{module-info.java}} that contains a {{requires 
> static}}, Surefire throws {{NoClassDefFoundError}} when running the tests for 
> that Maven module.
> If the dependency is declared only as {{required}} (no {{static}}), then the 
> tests run fine.
> Attached a reproducible project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to