Hi, Generally speaking the simplest way would be to let surefire load by reflection junit5 and auto open it. That said a solution like junit-platform maven plugin is more native when you need to control the command (the issue with jpms is you need to manually tune module and clqss paths, no exit to that not nice work).
So if the standard module duplication in test hack does not work i would just use a fork based plugin (junit-platform, exec with junit launcher, tool, ...) Maybe @sormuras can give us more insight but think it is our current status and until we have a fork provider surefire does not instrument or does with an agent (slow) we'll get this issue. Le dim. 17 sept. 2023 à 09:16, Henning Schmiedehausen < henn...@schmiedehausen.org> a écrit : > So I looked a bit more into that bug and why it crashes the way it crashes. > I also added this as a comment to the ticket but given the silence on most > tickets, I'd like to push for some discussion here on the mailing list. > > > I have two modules, core and testing (these are defined modules, they have > a module descriptor) > > "core" is just a regular build, it uses junit5 as its test framework. > > surefire creates a classpath with all the surefire deps (surefire-api, > surefire-extensions, surefire-junit-platform, surefire-logging-api, > surefire-shared-utils) and the junit deps (junit-jupiter-api, > junit-jupiter-engine, junit-jupiter-params, junit-platform-commons, > junit-platform-engine, junit-platform-launcher). The module path only gets > the actual module dependencies of module A > > All works well in that case. > > Now the "testing" module declares org.junit.jupiter.api as a dependency and > has requires org.junit.jupiter.api in its module descriptor (transitive or > not transitive does not matter) because there is code that implements some > of those APIs. > > surefire now creates a classpath with the same surefire deps and only a > subset of junit deps. The missing deps (junit-jupiter-api and > junit-platform-commons) are pulled onto the module path. > > This explains the error message: > > *java.lang.IllegalAccessError: class > org.junit.platform.launcher.core.LauncherDiscoveryRequestBuilder (in > unnamed module @0x6392827e) 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 @0x6392827e* > > The launcher (in junit-platform-launcher) lives on the classpath and is > therefore in the unnamed module. But the launcher requires the > org.junit.platform.commons module from the junit-platform-commons jar, > which is on the module path. And the junit-platform-commons module has the > following clause in its module descriptor: > > exports org.junit.platform.commons.util to > [...] > org.junit.platform.launcher, > [...]; > > and it does not export the package to the unnamed module. And now JVM fails > with the error above. > > I can not see any good solution: > > - The current solution does not work (see above) > - The junit-jupiter-api jar which contains org.junit.jupiter.api can not go > on the class path because now the main artifact which requires it can not > find it (the classes would be in the unnamed module and the main module > requests org.junit.jupiter.api) > - It can not be patched into the main module because now > the org.junit.jupiter.api module would be invisible to everything else on > the module path (packages can't exist twice) > - It can only stay on the module path if everything that depends on it gets > pulled there as well. This requires a "bottom up" resolution of all modules > that depend on this (in this case org.junit.jupiter.api) and may interfere > with the ability of the surefire launcher to launch code. > - We could fall back to "legacy" mode where everything is on the classpath > and the module path is ignored. This is problematic as tests may pass and > code later fails because of not matching entries in the module descriptor > > Thoughts? This seems to be a blocker for projects that want to use JPMS and > implement test code. > > -h >
