[
https://issues.apache.org/jira/browse/SUREFIRE-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
> 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
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
> [ERROR] at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
> [ERROR] at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
> [ERROR] at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
> [ERROR] at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
> [ERROR] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
> [ERROR] at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
> [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
> [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
> [ERROR] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> [ERROR] at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [ERROR] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [ERROR] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [ERROR] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [ERROR] at
> org.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:39)
> [ERROR] at
> org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:122)
> [ERROR] at
> org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:61)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
