[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611948#comment-17611948
]
Ceki Gülcü edited comment on SUREFIRE-1733 at 10/1/22 9:04 PM:
---
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing module (per Maven module under test) to bypass the monstrous
complexity involved in trying to test *everything* inside the same module
(under ./src/test/).
For example, if my module is called modX, I would create a modX-blackbox module
to test modX (in particular test jigsaw access) and the white-box tests would
go under modX/src/test/java as usual.
Unless I am missing something, the SharedSecrets mechanism is a way to make
certain objects or methods available indirectly through a _friend_ (C++
terminology) class in the same package. The slf4j-log4j12 module used a
[similar
technique|https://github.com/qos-ch/slf4j/blob/19e36ffdca0218797cd23048b6547865e30e1d3a/slf4j-log4j12/src/main/java/org/apache/log4j/MDCFriend.java]
for a long time.
was (Author: c...@qos.ch):
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing module (per Maven module under test) to bypass the monstrous
complexity involved in trying to test *everything* inside the same module
(under ./src/test/).
Unless I am missing something, the SharedSecrets mechanism is a way to make
certain objects or methods available indirectly through a _friend_ (C++
terminology) class in the same package. The slf4j-log4j12 module used a
[similar
technique|https://github.com/qos-ch/slf4j/blob/19e36ffdca0218797cd23048b6547865e30e1d3a/slf4j-log4j12/src/main/java/org/apache/log4j/MDCFriend.java]
for a long time.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611948#comment-17611948
]
Ceki Gülcü edited comment on SUREFIRE-1733 at 10/1/22 9:01 PM:
---
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing module (per Maven module under test) to bypass the monstrous
complexity involved in trying to test *everything* inside the same module
(under ./src/test/).
Unless I am missing something, the SharedSecrets mechanism is a way to make
certain objects or methods available indirectly through a _friend_ (C++
terminology) class in the same package. The slf4j-log4j12 module used a
[similar
technique|https://github.com/qos-ch/slf4j/blob/19e36ffdca0218797cd23048b6547865e30e1d3a/slf4j-log4j12/src/main/java/org/apache/log4j/MDCFriend.java]
for a long time.
was (Author: c...@qos.ch):
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing modules to bypass the monstrous complexity involved in trying
to test *everything* inside the same module (under ./src/test/).
Unless I am missing something, the SharedSecrets mechanism is a way to make
certain objects or methods available indirectly through a _friend_ (C++
terminology) class in the same package. The slf4j-log4j12 module used a
[similar
technique|https://github.com/qos-ch/slf4j/blob/19e36ffdca0218797cd23048b6547865e30e1d3a/slf4j-log4j12/src/main/java/org/apache/log4j/MDCFriend.java]
for a long time.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611948#comment-17611948
]
Ceki Gülcü edited comment on SUREFIRE-1733 at 10/1/22 8:53 PM:
---
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing modules to bypass the monstrous complexity involved in trying
to test *everything* inside the same module (under ./src/test/).
Unless I am missing something, the SharedSecrets mechanism is a way to make
certain objects or methods available indirectly through a _friend_ (C++
terminology) class in the same package. The slf4j-log4j12 module used a
[similar
technique|https://github.com/qos-ch/slf4j/blob/19e36ffdca0218797cd23048b6547865e30e1d3a/slf4j-log4j12/src/main/java/org/apache/log4j/MDCFriend.java]
for a long time.
was (Author: c...@qos.ch):
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing modules to bypass the monstrous complexity involved in trying
to test *everything* inside the same module (under ./src/test/).
Unless I am missing something, the SharedSecrets mechanism is a way to make
certain objects or methods available indirectly through a _friend_ (C++
terminology) class in the same package.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611983#comment-17611983
]
Gili edited comment on SUREFIRE-1733 at 10/1/22 8:44 PM:
-
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no modules aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
was (Author: cowwoc):
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no module aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611983#comment-17611983
]
Gili edited comment on SUREFIRE-1733 at 10/1/22 8:43 PM:
-
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no module aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
was (Author: cowwoc):
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no module aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611983#comment-17611983
]
Gili edited comment on SUREFIRE-1733 at 10/1/22 8:43 PM:
-
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push bridge functions, fields into it. It actually works the
other way as well ({*}test{*} can push bridge functions, fields into
{*}main{*}) but I've never needed to do this to date.
# Now, anytime *test* wishes to access the internals of {*}main{*}, it simply
piggybacks its calls through {*}SharedSecrets{*}.
# Lastly, because no module aside from *main* and *test* have access to
{*}SharedSecrets{*}, your API internals remain hidden.
Does that address your concerns?
was (Author: cowwoc):
Hi Ceki,
Thank you for catching the typo in my Stackoverflow post :) I will repeat the
link here for the benefit of other readers:
[https://stackoverflow.com/a/46723089/14731]
I didn't fully understand your last post so please excuse me if I'm repeating
something that you've already understood.
The SharedSecrets mechanism allows a class defined *outside* of a Java Module
to access anything that it could access from *inside* the module. You don't
need one SharedInstance class per package. One class per module is enough.
It works like this:
# Say you have two modules: *main* and {*}test{*}, and you want *test* to
access private or package-private methods inside {*}main{*}.
# Declare a public class *SharedSecrets* class inside the main module, in a
non-exported package. For example: {*}main.internal.SharedSecrets{*}.
# In {*}main{*}'s {*}module-info.java{*}, add {*}exports main.internal to
test{*}. Meaning, the package *main.internal* will only be accessible to module
{*}test{*}.
# Now, anyone in *main* wishing to give *test* access to its internals needs
to give {*}main.internal.SharedSecrets{*}.
# *test* then piggybacks any calls it wants to make through *SharedSecrets* as
outlined in the stackoverflow post.
Because *SharedSecrets* is public, anyone in *main* (even from different
packages) can push "bridge functions" into it. It actually works the other way
as well ({*}test{*} can push bridge functions into {*}main{*}) but I've never
needed this to date.
Does that address your concerns?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611948#comment-17611948
]
Ceki Gülcü edited comment on SUREFIRE-1733 at 10/1/22 8:37 PM:
---
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing modules to bypass the monstrous complexity involved in trying
to test *everything* inside the same module (under ./src/test/).
Unless I am missing something, the SharedSecrets mechanism is a way to make
certain objects or methods available indirectly through a _friend_ (C++
terminology) class in the same package.
was (Author: c...@qos.ch):
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing modules to bypass the monstrous complexity involved in trying
to test *everything* inside the same module (under ./src/test/).
If I understand correctly, the SharedSecrets mechanism is a way to make certain
objects or methods available indirectly through a _friend_ class in the same
package.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611948#comment-17611948
]
Ceki Gülcü edited comment on SUREFIRE-1733 at 10/1/22 7:02 PM:
---
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing modules to bypass the monstrous complexity involved in trying
to test *everything* inside the same module (under ./src/test/).
If I understand correctly, the SharedSecrets mechanism is a way to make certain
objects or methods available indirectly through a _friend_ class in the same
package.
was (Author: c...@qos.ch):
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing modules to bypass the monstrous complexity involved in trying
to test *everything* inside the same module (under ./src/test/).
If I understand correctly, the SharedSecrets mechanism is a way to make certain
objects or methods available indirectly through a _friend _class in the same
package.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611948#comment-17611948
]
Ceki Gülcü edited comment on SUREFIRE-1733 at 10/1/22 7:02 PM:
---
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing modules to bypass the monstrous complexity involved in trying
to test *everything* inside the same module (under ./src/test/).
If I understand correctly, the SharedSecrets mechanism is a way to make certain
objects or methods available indirectly through a _friend _class in the same
package.
was (Author: c...@qos.ch):
Hi Gili,
Thank you for pointing out the difference between white-box testing and
black-box testing. You are right. there is actually *no* need for white-box
testing when validating Jigsaw module access. I just need to create a separate
black-box testing modules to bypass the monstrous complexity involved in trying
to test *everything* inside the same module (under ./src/test/).
I am not aware of the SharedSecrets mechanism.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611915#comment-17611915
]
Gili edited comment on SUREFIRE-1733 at 10/1/22 2:18 PM:
-
Hi Ceki,
What kind of bugs would you be testing for exactly? White-box testing, by
definition, focuses on testing implementation details as opposed to the
business requirements, so I am used to it being used to test private methods.
The only JPMS-specific white-box test that I can think of is ensuring that the
module being tested has access to some other module. And then I wonder why
you'd need to test for this using white-box testing. If this inter-module
access doesn't have any impact that is visible to black-box testing, then
what's the point of testing for it?
Also, you can do any kind of white-box testing you want, from outside the
module, using the SharedSecrets mechanism. This works perfectly, without having
to hack the modules in any way.
was (Author: cowwoc):
Hi Ceki,
What kind of bugs would you be testing for exactly? White-box testing, by
definition, focuses on testing implementation details as opposed to the
business requirements, so I am used to it being used to test orivate methods.
The only JPMS-specific white-box test that I can think of is ensuring that the
module being tested has access to some other module. And then I wonder why
you'd need to test for this using white-box testing. If this inter-module
access doesn't have any impact that is visible to black-box testing, then
what's the point of testing for it?
Also, you can do any kind of white-box testing you want, from outside the
module, using the SharedSecrets mechanism. This works perfectly, without having
to hack the modules in any way.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130)
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611844#comment-17611844
]
Ceki Gülcü edited comment on SUREFIRE-1733 at 10/1/22 9:53 AM:
---
I think preserving the white-box testing model in a fully JPMS-modularized
project is a worthwhile goal. I am aware that setting
-Dsurefire.useModulePath=false can achieves that by putting everything on the
class path. However, that defeats the purpose of testing JMPS modular
dependencies. By white-box modular testing, I mean testing with all or most
modular artifacts being placed on the modular-path.
I wish there was a way in the a dependency declaration in the POM allowing
users to control the path in which an artifact is placed (class-path or the
module-path).
was (Author: c...@qos.ch):
I think preserving the white-box testing model in a fully JPMS-modularized
project is a worthwhile goal. I am aware that setting
-Dsurefire.useModulePath=false can achieves that by putting everything on the
class path. However, that defeats the purpose of testing JMPS modular
dependencies. By white-box modular testing, I mean testing with all modular
artifacts being placed on the modular-path.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Assignee: Tibor Digana
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095876#comment-17095876
]
Gili edited comment on SUREFIRE-1733 at 4/29/20, 8:37 PM:
--
[~sor] I guess it's a subjective decision because from my point of view there
is nothing wrong with such qualified exports.
1. If this kind of usage of bad, what constitutes good usage of qualified
exports?
2. Users of my API don't need to (and shouldn't) dig into my
`module-info.java`. They just need to `requires API`. Similarly for `pom.xml`.
Why would anyone need to dig into it? It's enough to know my
`groupId:artifactId` (equivalent to my module name).
Anyway, getting back to the original point: even if you want to use
--patch-module in place of qualified exports, I'd still like to be able to
specify a separate `module-info.java` for "test" and "main" modules because my
test module needs additional dependencies that main does not (e.g. the
HttpClient example I mentioned above).
With respect to missing modules: `javac` will issue a warning but you can
suppress this (and I do when it makes sense). `java` will not complain.
was (Author: cowwoc):
[~sor] I guess it's a subjective decision because from my point of view there
is nothing wrong with such qualified exports.
1. If this kind of usage of bad, what constitutes good usage of qualified
exports?
2. Users of my API don't need to (and shouldn't) dig into my
`module-info.java`. They just need to `requires API`. Similarly for `pom.xml`.
Why would anyone need to dig into it? It's enough to know my
`groupId:artifactId` (equivalent to my module name).
Anyway, getting back to the original point: even if you want to use
--patch-module in place of qualified exports, I'd still like to be able to
specify a separate `module-info.java` for "test" and "main" modules because my
test module needs additional dependencies that main does not (e.g. the
HttpClient example I mentioned above).
With respect to missing modules: javac will issue a warning but you can
suppress this (and I do when it makes sense). java will not complain.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095876#comment-17095876
]
Gili edited comment on SUREFIRE-1733 at 4/29/20, 8:37 PM:
--
[~sor] I guess it's a subjective decision because from my point of view there
is nothing wrong with such qualified exports.
1. If this kind of usage of bad, what constitutes good usage of qualified
exports?
2. Users of my API don't need to (and shouldn't) dig into my
`module-info.java`. They just need to `requires API`. Similarly for `pom.xml`.
Why would anyone need to dig into it? It's enough to know my
`groupId:artifactId` (equivalent to my module name).
Anyway, getting back to the original point: even if you want to use
--patch-module in place of qualified exports, I'd still like to be able to
specify a separate `module-info.java` for "test" and "main" modules because my
test module needs additional dependencies that main does not (e.g. the
HttpClient example I mentioned above).
With respect to missing modules: javac will issue a warning but you can
suppress this (and I do when it makes sense). java will not complain.
was (Author: cowwoc):
[~sor] I guess it's a subjective decision because from my point of view there
is nothing wrong with such qualified exports.
1. If this kind of usage of bad, what constitutes good usage of qualified
exports?
2. Users of my API don't need to (and shouldn't) dig into my
`module-info.java`. They just need to `requires API`. Similarly for `pom.xml`.
Why would anyone need to dig into it? It's enough to know my
`groupId:artifactId` (equivalent to my module name).
Anyway, getting back to the original point: even if you want to use
--patch-module in place of qualified exports, I'd still like to be able to
specify a separate `module-info.java` for "test" and "main" modules because my
test module needs additional dependencies that main does not (e.g. the
HttpClient example I mentioned above).
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException:
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095861#comment-17095861
]
Christian Stein edited comment on SUREFIRE-1733 at 4/29/20, 8:07 PM:
-
We are not talking about having those qualified export directives declared in
your "main" modules? Targeting internal modules that are never published? And
openening your "main" modules to testing framework that utilize reflection?
> you just need to "exports INTERNAL to TEST" in module API.
No. Way. Via `exports INTERNAL to TEST;` within the "main" API module
descriptor.
So, you're about command line flags like: `--add-exports` and friends?
was (Author: sor):
We are not talking about having those qualified export directives declared in
your "main" modules? Targeting internal modules that are never published? And
openening your "main" modules to testing framework that utilize reflection?
> you just need to "exports INTERNAL to TEST" in module API.
No. Way.
So, you're about command line flags like: `--add-exports` and friends?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095861#comment-17095861
]
Christian Stein edited comment on SUREFIRE-1733 at 4/29/20, 8:06 PM:
-
We are not talking about having those qualified export directives declared in
your "main" modules? Targeting internal modules that are never published? And
openening your "main" modules to testing framework that utilize reflection?
> you just need to "exports INTERNAL to TEST" in module API.
No. Way.
So, you're about command line flags like: `--add-exports` and friends?
was (Author: sor):
We are not talking about having those qualified export directives declared in
your "main" modules? Targeting internal modules that are never published? And
openening your "main" modules to testing framework that utilize reflection?
So, you're about command line flags like: `--add-exports` and friends?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17095465#comment-17095465
]
Gili edited comment on SUREFIRE-1733 at 4/29/20, 2:50 PM:
--
I've got a slightly use-case where the test module needs a different set of
dependencies than "main":
https://issues.apache.org/jira/browse/SUREFIRE-1755?focusedCommentId=17094996=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17094996
I don't think Robert's proposal of "additionalModules" is flexible enough (for
example, you can't specify "opens" or "exports ... to"). I'd like to raise an
alternate proposal:
1. If the "test" module does not contain module-info.java, fallback on the old
behavior before JPMS. We'd need to decide (in this discussion) whether to run
on the classpath or modulepath. It's probably easier to run on the classpath
and be done with it. If we want to try running on the modulepath, I'd expect
Surefire to inherit module-info.java from "main" and patch it as needed to be
able to run junit/testng.
2. If the "test" module contains its own module-info.java, treat it as an
independent module. In this case, the user is specify that the test module
"requires" the main module and whatever else they might need to run unit tests
(including junit/testng). No magic.
This gives us backwards compatibility in option 1 and full module support in
option 2. What do you think?
was (Author: cowwoc):
I've got a slightly use-case where the test module needs a different set of
dependencies than "main":
https://issues.apache.org/jira/browse/SUREFIRE-1755?focusedCommentId=17094996=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17094996
I don't think Robert's proposal of "additionalModules" is flexible enough (for
example, you can't specify "opens" or "exports ... to". I'd like to raise an
alternate proposal:
1. If the "test" module does not contain module-info.java, fallback on the old
behavior before JPMS. We'd need to decide (in this discussion) whether to run
on the classpath or modulepath. It's probably easier to run on the classpath
and be done with it. If we want to try running on the modulepath, I'd expect
Surefire to inherit module-info.java from "main" and patch it as needed to be
able to run junit/testng.
2. If the "test" module contains its own module-info.java, treat it as an
independent module. In this case, the user is specify that the test module
"requires" the main module and whatever else they might need to run unit tests
(including junit/testng). No magic.
This gives us backwards compatibility in option 1 and full module support in
option 2. What do you think?
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Fix For: 3.0.0-M5
>
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT:
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989624#comment-16989624
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/6/19 10:43 AM:
--
[~rfscholte]
Why to distinguish for separate providers?
Because the users don't mind about our Surefire providers and junit5 engines.
And the user's are right in their view because they need to see their test code
only and that's why they report these issues.
Look, there is very nice option where the user specifies only one dependency in
the POM.
It is {{junit-jupiter-api}} and no engine. The plugin can activate the
{{junit-jupiter-engine}} and the provider too of course. So the plugin can see
the version of the API and add this engine to CP. Pretty nice and simple for
the users because the users do not have to mind about our magic. They need to
know that their tests will be executed and they know that the engine would be
selected together with the provider.
Why this issue happened?
Because the old versions (5.3.x - 5.4.x) of JUnit5 did not contain
{{module-info}} and we did not expect that these issues would happen and we
simply placed the libs on CP instead of MP. Higher versions already have the
{{module-info}}.
was (Author: tibor17):
[~rfscholte]
Why to distinguish for separate providers?
Because the users don't mind about our Surefire providers and junit5 engines.
And the user's are right in their view because they need to see their test code
only and that's why they report these issues.
Look, there is very nice option where the user specifies only one dependency in
the POM.
It is {{junit-jupiter-api}} and no engine. The plugin can activate the
{{junit-jupiter-engine}} and the provider too of course. So the plugin can see
the version of the API and add this engine to CP. Pretty nice and simple for
the users because the users do not have to mind about our magic. They need to
know that their tests will be executed and they know that the engine would be
selected together with the provider.
Why this issue happened?
Because the old versions (5.3.x - 5.4.x) of JUnit5 did not contain
{{module-info}} and we did not expect that these issues would happen and we
simply placed them on CP instead of MP. Higher versions already have the
{{module-info}}.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989498#comment-16989498
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/6/19 8:17 AM:
-
[~rfscholte]
Pls see my comment properly. There i am only trying to explain that we should
distinguish between user's artifacts and our internal artifacts means Surefire
provider libs.
I have one more question regarding the terminology with a provider in
plexus-java.
What is the Plexus' provider and how it is related to Surefire? I saw the code
in [1] but I can see only boolean and I do not see any Collection with
providers or explanation what it is. Thx
[1]:
github.com/codehaus-plexus/plexus-languages/blob/master/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/ResolvePathsRequest.java#L225
was (Author: tibor17):
[~rfscholte]
Pls see my comment properly. There i am only trying to explain that we should
distinguish between user's artifacts an dout internal artifacts means Surefire
provider libs.
I have one more question regarding the terminology with a provider in
plexus-java.
What is the Plexus' provider and how it is related to Surefire. I saw the code
in [1] but I can see only boolean and I do not see any Collection with
providers or explanation what it is. Thx
[1]:
github.com/codehaus-plexus/plexus-languages/blob/master/plexus-java/src/main/java/org/codehaus/plexus/languages/java/jpms/ResolvePathsRequest.java#L225
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989277#comment-16989277
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/6/19 8:02 AM:
-
[~rfscholte]
See my comment in
https://issues.apache.org/jira/browse/SUREFIRE-1733?focusedCommentId=16987975=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16987975
It says that both libraries contain {{module-info.class}} and therefore they
are *Java Modularity capable*. What is contradictory is the fact that these two
libraries are in classpath instead of module path. Of course you do not have
them in modulepath because the user does not specify these (see Surefire
*provider's deps*) libraries in his {{module-info.java}} but the thing is that
he is not expected to complicate his life with doing it because it is our
responsibility and we are not doing it. As a result these libs appear on
classpath and this is the visibility problem:
{noformat}
class org.junit.platform.launcher.core.LauncherFactory (in unnamed module
@0x6eceb130) cannot access class org.junit.platform.commons.util.Preconditions
(in module org.junit.platform.commons) because module
org.junit.platform.commons does not export org.junit.platform.commons.util to
unnamed module @0x6eceb130
{noformat}
was (Author: tibor17):
[~rfscholte]
See my comment in
https://issues.apache.org/jira/browse/SUREFIRE-1733?focusedCommentId=16987975=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16987975
It says that both libraries contain {{module-info.class}} and therefore they
are *Java Modularity capable*. What is contradictory is the fact that these two
libraries are in classpath instead of module path. Of course you do not have
them in modulepath because the user does not specify these (see Surefire
*provider's deps*) libraries in his {{module-info.java}} but the thing is that
he is not expected to complicate his life doing it because it is our
responsibility and we are not doing it. As a result these libs appear on
classpath and this is the visibility problem:
{noformat}
class org.junit.platform.launcher.core.LauncherFactory (in unnamed module
@0x6eceb130) cannot access class org.junit.platform.commons.util.Preconditions
(in module org.junit.platform.commons) because module
org.junit.platform.commons does not export org.junit.platform.commons.util to
unnamed module @0x6eceb130
{noformat}
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989277#comment-16989277
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/6/19 12:35 AM:
--
[~rfscholte]
See my comment in
https://issues.apache.org/jira/browse/SUREFIRE-1733?focusedCommentId=16987975=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16987975
It says that both libraries contain {{module-info.class}} and therefore they
are *Java Modularity capable*. What is contradictory is the fact that these two
libraries are in classpath instead of module path. Of course you do not have
them in modulepath because the user does not specify these (see Surefire
*provider's deps*) libraries in his {{module-info.java}} but the thing is that
he is not expected to complicate his life doing it because it is our
responsibility and we are not doing it. As a result these libs appear on
classpath and this is the visibility problem:
{noformat}
class org.junit.platform.launcher.core.LauncherFactory (in unnamed module
@0x6eceb130) cannot access class org.junit.platform.commons.util.Preconditions
(in module org.junit.platform.commons) because module
org.junit.platform.commons does not export org.junit.platform.commons.util to
unnamed module @0x6eceb130
{noformat}
was (Author: tibor17):
[~rfscholte]
See my comment in
https://issues.apache.org/jira/browse/SUREFIRE-1733?focusedCommentId=16987975=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16987975
It says that both libraries contain {{module-info.class}} and therefore they
are *Java Modularity capable*. What is contradictory is the fact that these two
libraries are in classpath instead of module path. Of course you do not have
them in modulepath because the user does not specify these libraries in his
{{module-info.java}} but the thing is that he is not expected to complicate his
life doing it because it is our responsibility and we are not doing it. As a
result these libs appear on classpath and this is the visibility problem:
{noformat}
class org.junit.platform.launcher.core.LauncherFactory (in unnamed module
@0x6eceb130) cannot access class org.junit.platform.commons.util.Preconditions
(in module org.junit.platform.commons) because module
org.junit.platform.commons does not export org.junit.platform.commons.util to
unnamed module @0x6eceb130
{noformat}
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR]
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989199#comment-16989199
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/5/19 9:55 PM:
-
> Main question: based on which module-descriptor should plexus-java decide to
> add the launcher to the module-path?
A good question.
I think the provider libraries are defined by Surefire deps. The merge with
engines is dynamically computed. (I don't need to fix test deps processing with
plexus-java because this works fine) I only need to check each library whether
it is Java Modularity capable. _IF capable THEN move the lib to MP, ELSE move
it to CP._ This is my understanding so far. Pls comment on this, thx.
was (Author: tibor17):
> Main question: based on which module-descriptor should plexus-java decide to
> add the launcher to the module-path?
A good question.
I think the provider libraries are defined. The merge with engines is defined
as well. I only need to check each library whether it is Java Modularity
capable. _IF capable THEN move the lib to MP, ELSE move it to CP._ This is my
understanding so far. Pls comment on this, thx.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16989199#comment-16989199
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/5/19 9:56 PM:
-
> Main question: based on which module-descriptor should plexus-java decide to
> add the launcher to the module-path?
A good question.
I think the provider libraries are defined by Surefire deps. The merge with
engines is dynamically computed. (I don't need to fix test deps processing with
plexus-java because this works fine) I only need to check each library in
provider path whether it is Java Modularity capable. _IF capable THEN move the
lib to MP, ELSE move it to CP._ This is my understanding so far. Pls comment on
this, thx.
was (Author: tibor17):
> Main question: based on which module-descriptor should plexus-java decide to
> add the launcher to the module-path?
A good question.
I think the provider libraries are defined by Surefire deps. The merge with
engines is dynamically computed. (I don't need to fix test deps processing with
plexus-java because this works fine) I only need to check each library whether
it is Java Modularity capable. _IF capable THEN move the lib to MP, ELSE move
it to CP._ This is my understanding so far. Pls comment on this, thx.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
> Attachments: surefire-v2.22.2_junit-v5.5.2.txt,
> surefire-v2.22.2_junit-v5.6.0-M1.txt, surefire-v3.0.0-M4_junit-v5.5.2.txt,
> surefire-v3.0.0-M4_junit-v5.6.0-M1.txt
>
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
>
[jira] [Comment Edited] (SUREFIRE-1733) Surefire and Failsafe JPMS additions for JUnit 5.x execution
[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16988100#comment-16988100
]
Tibor Digana edited comment on SUREFIRE-1733 at 12/4/19 6:59 PM:
-
Why you selected 3.0.0-M4 as well in Jira?
This version changed the classpath resolution for JUnit5 provider. It could
simply happen in 2.22.2 that the {{junit-platform-launcher}} used old version
1.3.0 but the rest of libraries much higher means 5.5.2 and 1.5.2. The old
version 1.3.0 des not have {{module-info}}.
was (Author: tibor17):
Why you selected 3.0.0-M4?
This version changed the classpath resolution for JUnit5 provider. It could
simply happen in 2.22.2 that the {{junit-platform-launcher}} used old version
1.3.0 but the rest of libraries much higher means 5.5.2 and 1.5.2. The old
version 1.3.0 des not have {{module-info}}.
> Surefire and Failsafe JPMS additions for JUnit 5.x execution
>
>
> Key: SUREFIRE-1733
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1733
> Project: Maven Surefire
> Issue Type: Improvement
> Components: Maven Failsafe Plugin, Maven Surefire Plugin
>Affects Versions: 2.22.2, 3.0.0-M4
>Reporter: John Patrick
>Priority: Minor
>
> Following on from SUREFIRE-1731 it was highlighted that some projects need
> extra '--add-open' options for JUnit to execute correctly, lots have already
> been handled or added or supported in previous releases but I'm needing to
> add these for a project to run correctly.
> I'm happy to start looking at a patch, but need help with where repo or class
> to start looking at.
> This is what extra arguments I'm needing to pass to surefire/failsafe.
> {code}
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=ALL-UNNAMED
> --add-opens
> ${project.Automatic-Module-Name}/${project.Automatic-Module-Name}=org.junit.platform.commons
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.util=ALL-UNNAMED
> --add-opens
> org.junit.platform.commons/org.junit.platform.commons.logging=ALL-UNNAMED
> {code}
> Luckly my module names and package names are all on the same standard and
> I've got a maven property for each sub module defining what
> 'project.Automatic-Module-Name' is.
> The 2nd two are probably easy and will work for everyone, the 1st two might
> require some discussion and maybe define two variables that surefire and
> failsafe can use, one for the module name and one for the package name if
> they can dynamically scan the source code and work it out.
> This is the stacktrace I'm seeing;
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.22.2:test (default-test) on
> project PROJECT: There are test failures.
> [ERROR]
> [ERROR] Please refer to PATH/target/surefire-reports for the individual test
> results.
> [ERROR] Please refer to dump files (if any exist) [date].dump,
> [date]-jvmRun[N].dump and [date].dumpstream.
> [ERROR] There was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There
> was an error in the forked process
> [ERROR] java.lang.IllegalAccessError: class
> org.junit.platform.launcher.core.LauncherFactory (in unnamed module
> @0x6eceb130) cannot access class
> org.junit.platform.commons.util.Preconditions (in module
> org.junit.platform.commons) because module org.junit.platform.commons does
> not export org.junit.platform.commons.util to unnamed module @0x6eceb130
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:656)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:282)
> [ERROR] at
> org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:245)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1183)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1011)
> [ERROR] at
> org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:857)
> [ERROR] at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
> [ERROR] at
>
