[
https://issues.apache.org/jira/browse/SUREFIRE-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097238#comment-17097238
]
Gili edited comment on SUREFIRE-1563 at 5/1/20, 8:25 AM:
---------------------------------------------------------
My reading of
https://youtrack.jetbrains.com/issue/IDEA-222831#focus=streamItem-27-3915365.0-0
is that IntelliJ IDEA 2020.1 does not support the `module-info.test` and I
agree with Robert that {{module-info.test}} isn't necessarily the right way to
go. I sympathize with Christian. He brought up legitimate concerns. I am just
hopeful that we can come up with a more polished, non-proprietary solution.
I would prefer this configuration sit in Maven, Gradle, etc than in an external
file (such as module-info.test) but to Stephen's point the problem is that
"users are forced to learn the low level `add-modules` and `add-opens` commands
for what should be straightforward testing tasks once a `module-info.java` is
added."
Ideally, I'd like to see users specify "intent" in the build file, as opposed
to individual command-line options.
{{{
<configuration>
<moduleType>whitebox-testing</moduleType>
// or...
<moduleType>blackbox-testing</moduleType>
</configuration>
}}}
Maybe the syntax is ugly but you get my point. Alternatively, maybe we can
detect user intent based on the contents of {{test/main/module-info.java}}. The
point is that I want to communicate in terms of high-level goals not low-level
command-line options. Surefire would then pass the necessary command-line
options under the hood to meet this goal.
Let's please dig further into solving this more cleanly. Baring that, I'd vote
for Robert's proposal of specifying additional command lines in the {{pom.xml}}
file.
[~rfscholte] If we are forced to go down this road, what's the benefit of
introducing {{<addModule>}}, {{<addOpen>}} versus letting users append
arbitrary command-line options?
was (Author: cowwoc):
My reading of
https://youtrack.jetbrains.com/issue/IDEA-222831#focus=streamItem-27-3915365.0-0
is that IntelliJ IDEA 2020.1 does not support the `module-info.test` and I
agree with Robert that {{module-info.test}} isn't necessarily the right way to
go. I sympathize with Christian. He brought up legitimate concerns. I am just
hopeful that we can come up with a more polished, non-proprietary solution.
I would prefer this configuration sit in Maven, Gradle, etc than in an external
file (such as module-info.test) but to Stephen's point the problem is that
"users are forced to learn the low level `add-modules` and `add-opens` commands
for what should be straightforward testing tasks once a `module-info.java` is
added."
Let's please dig further into solving this more cleanly. Baring that, I'd vote
for Robert's proposal of specifying additional command lines in the {{pom.xml}}
file.
[~rfscholte] If we are forced to go down this road, what's the benefit of
introducing {{<addModule>}}, {{<addOpen>}} versus letting users append
arbitrary command-line options?
> 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)
