I manage several GitHub repositories, a multitude of which use Spring. One of these projects is our Spring AoT extension, for Axon Framework.

To ensure we're on track with the latest releases, we use dependabot to automatically update our dependencies.

As off release 6.2.4, upgraded in this PR, the mvn test goal fails with the following exception:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.5.2:test (default-test) on project axon-spring-aot: 
[ERROR] 
[ERROR] See /home/***/extension-spring-aot/target/surefire-reports for the individual test results.
[ERROR] See dump files (if any exist) [date].dump, [date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] There was an error in the forked process
[ERROR] org/junit/platform/engine/reporting/OutputDirectoryProvider
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: There was an error in the forked process
[ERROR] org/junit/platform/engine/reporting/OutputDirectoryProvider
[ERROR]     at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:628)
[ERROR]     at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:285)
[ERROR]     at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:250)
[ERROR]     at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1336)
[ERROR]     at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1134)
[ERROR]     at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:968)
[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:957)
[ERROR]     at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:289)
[ERROR]     at org.apache.maven.cli.MavenCli.main(MavenCli.java:193)
[ERROR]     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR]     at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
[ERROR]     at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR]     at java.base/java.lang.reflect.Method.invoke(Method.java:569)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
[ERROR]     at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
[ERROR]     at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
[ERROR] 
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Although I wager this behavior is impacted by the maven-surefire-plugin we use, the predicament is resolved when downgrade the Spring dependencies to 6.2.3.

As such, I figured it would be worth to share this here. If anybody wants to try out this failure, please use the referred to dependabot PR.

Comment From: sbrannen

Hi @smcvb,

Congratulations on submitting your first issue for the Spring Framework! 👍

Although I wager this behavior is impacted by the maven-surefire-plugin we use, the predicament is resolved when downgrade the Spring dependencies to 6.2.3.

I find that quite intriguing, and I think I'll take a look at that PR to get to the bottom of it.

In any case, the org.junit.platform.engine.reporting.OutputDirectoryProvider mentioned in the stack trace was introduced in JUnit 5.12 (specifically JUnit Platform 1.12).

Thus, I assume your PR may work if you upgrade your junit.jupiter.version property from 5.10.1 to 5.12.1.

Can you please give that a try and let me know if it works?

Comment From: smcvb

In any case, the org.junit.platform.engine.reporting.OutputDirectoryProvider mentioned in the stack trace was introduced in JUnit 5.12 (specifically JUnit Platform 1.12).

Ow, that's a great catch, @sbrannen! After changing the junit.jupiter.version property in our pom.xml to 5.12.1 it, however, still didn't work.

So, I started digging a little in the pom. As a matter of fact, we never included a dependency on the junit-jupiter artifact at all... Must have been a copy/paste error on our end (we manage a multitude of extensions like this).

After adding a test dependency on junit-jupiter, the problem got resolved. I did also verify if the exception persisted with 5.10.1 in combination with the added dependency, and it did.

Thus, concluding, the solution was twofold:

  1. Add junit-jupiter test-scoped dependency.
  2. Set version to latest (5.12.1).

With that, I feel confident to close this ticket succesfully. Thanks for the input, @sbrannen! 🙏

Comment From: sbrannen

I find that quite intriguing, and I think I'll take a look at that PR to get to the bottom of it.

It turns out the cause for this unexpected behavior is three-fold.

  1. spring-core-test has a required transitive dependency on junit-jupiter-api. https://github.com/spring-projects/spring-framework/blob/8ee09e57661d9ea95bcc64fc933b46cdf3b3feb9/spring-core-test/spring-core-test.gradle#L6
  2. We recently upgraded our build to use JUnit 5.12.x, and that got backported to 6.2.x in https://github.com/spring-projects/spring-framework/commit/387677eae8ebc2b641e24d274c87980743c6d1cc.
  3. Consequently, spring-core-test 6.2.4 now pulls in junit-jupiter-api 5.12.0 transitively.

All is not lost, however. If you read the JUnit 5 User Guide, you'll note that you can use the junit-bom to align the JUnit versions used in your build.

I got your build working with Spring Framework 6.2.4 as follows.

Upgrade Spring Framework version.

<spring.version>6.2.4</spring.version>

Delete (or comment out) the explicit junit.jupiter.version property.

<!-- <junit.jupiter.version>5.10.1</junit.jupiter.version> -->

Use the junit-bom to align versions.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.junit</groupId>
            <artifactId>junit-bom</artifactId>
            <version>5.10.1</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

That works with JUnit 5.10.1 and Spring Framework 6.2.4.

You can also change the JUnit version to 5.12.1, and it still works with Spring Framework 6.2.4.

And I now see that you've closed this issue while I was typing this. 👀

Comment From: sbrannen

Thus, concluding, the solution was twofold:

  1. Add junit-jupiter test-scoped dependency.
  2. Set version to latest (5.12.1).

I'm glad to hear that worked for you!

However, I would still recommend that you use the junit-bom as I outlined above.

Thanks for the input, @sbrannen! 🙏

You're very welcome!

Comment From: smcvb

Switching to the junit-bom is tremendously easy, and what we recommend for our projects too. Makes sense to make that adjustment. Thanks for the suggestion, @sbrannen!