[
https://issues.apache.org/jira/browse/SUREFIRE-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17390481#comment-17390481
]
Tibor Digana commented on SUREFIRE-1909:
----------------------------------------
[~c...@newsclub.de]
There are two modules.
It is not true that you have one module. Form the JPMS perspective there are
two, namely, {{src/main/java}} and {{src/test/java}}.
So if you need to maintain tests as a jpms module, you should have module info
in tests as well. If you do not then the test dependencies would appear in the
classpath. If you want to have them in module path, you have to write
module-info.java in src/test/java. We cannot have one module descriptor because
these two modules are isolated, they must be two and they are different, cannot
be mixed in one module descriptor. For instance the compiler is using module
descriptor in src/main/java. I guess the compiler would do similar with module
descriptor in src/test/java.
I can imaging that we would add a new configuration parameter where you would
be able to specify file path pointing to your custom module descriptor where
you can merge both in one. I think you do not have comfort either with this.
We cannot read your brain and we do not know when and what user wants to use
"add-export" and when not. Therefore you are managing the modulepaths.
If you have a help and a solution for us, I am all the hear.
Maybe we would need to have {{--module-path}}
"workspace/surefire-jpms-bug/target/classes" +
"workspace/surefire-jpms-bug/target/test-classes".
Let me know your solution.
> Support JUnit 5 reflection access by changing add-exports to add-opens
> ----------------------------------------------------------------------
>
> Key: SUREFIRE-1909
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1909
> Project: Maven Surefire
> Issue Type: Bug
> Components: JUnit 5.x support
> Affects Versions: 3.0.0-M5
> Reporter: Christian Kohlschütter
> Priority: Major
> Attachments: surefire-jpms-bug.tar.gz
>
>
> Testing JUnit 5 classes of a JPMS-enabled project with Surefire may fail if a
> test class (or, for example, an abstract test base class) is not declared
> "public". I'm seeing the following error:
>
> {code:java}
> java.lang.reflect.InaccessibleObjectException: Unable to make public static
> void some.package.SomeClass.setupClass() throws java.io.IOException
> accessible: module some.module does not "opens some.package" to unnamed
> module @754ba872{code}
> This could be fixed by adding the recommended "{{opens some.package}}" to the
> project's module-info.java, however that is undesirable since it changes the
> project's behavior beyond just unit testing. Adding a secondary "test-only"
> module-info.java is also counterproductive since not all IDEs support this,
> and these two files would have to be kept in sync, which is non-trivial.
> An easy fix would be to change the "{{--add-exports-}}" VM parameter that
> surefire adds automatically to "{{-}}{{add-opens}}" in
> {{maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/booterclient/ModularClasspathForkConfiguration.java}}
> This bug is particularly bad because PMD now specifically complains about
> junit5 classes marked as public instead of package-private; see
> [https://pmd.github.io/2021/05/29/PMD-6.35.0/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
