[jira] [Comment Edited] (SUREFIRE-1563) NoClassDefFoundError for JPMS modules with "require static"

["Gili (Jira)" <ji...@apache.org>]

    [ 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)