Maven surefire could not find ForkedBooter class

Encountering the frustrating “Maven surefire could not find ForkedBooter class” error can halt your Java project’s progress, leaving you scratching your head. This common issue arises during the test execution phase in Maven, indicating a problem with how the surefire plugin is configured or with dependencies within your project. It typically means that the plugin is unable to properly isolate and run tests in a separate JVM. Understanding the root causes and troubleshooting steps is crucial for resolving this error and ensuring your tests run smoothly. This guide will delve into the common culprits behind this error, provide practical solutions, and offer best practices to prevent it from recurring, helping you maintain a robust and reliable build process.

Understanding the “Maven Surefire Could Not Find ForkedBooter Class” Error

The “Maven surefire could not find ForkedBooter class” error is a runtime exception that surfaces during the execution of unit or integration tests within a Maven project. It signals that the org.apache.maven.surefire.booter.ForkedBooter class, responsible for launching tests in a forked JVM process, is not accessible to the surefire plugin. This typically occurs when the classpath configuration is incorrect, dependencies are missing, or there’s a version incompatibility between the surefire plugin and other libraries in the project. The surefire plugin is a core component of Maven, designed to discover and run unit tests conforming to JUnit or TestNG standards. When it cannot locate the necessary classes to fork a process, the test execution fails, leading to build failures and potential deployment delays.

Several factors can contribute to this error. One common reason is a misconfiguration in the pom.xml file, where the surefire plugin version might not be compatible with the project’s Java version or other dependencies. Another potential cause is dependency conflicts, where different versions of libraries required by the surefire plugin are present in the classpath. Incorrect project structure, especially in multi-module projects, can also lead to classpath issues. Furthermore, customized forking configurations within the surefire plugin itself, if not properly set up, can trigger this error. Debugging this requires careful examination of the Maven build logs, the pom.xml file, and the project’s dependency tree to identify the source of the problem. Resolving the dependency issues is very important.

According to the Maven documentation, the surefire plugin’s primary function is to execute tests during the test phase of the Maven lifecycle. When the plugin forks a new JVM process for test execution, it relies on the ForkedBooter class to initialize and manage the process. If the classpath is not correctly set up, or if the required dependencies are not available in the forked process’s classpath, the plugin will be unable to find this class, resulting in the error. Examining the Maven build logs with the -X (debug) option can provide detailed information about the classpath used during test execution, which can help pinpoint the missing or conflicting dependencies. Maven Surefire Plugin Documentation provides detailed insights into the configuration options.

Common Causes and Troubleshooting Steps

Pinpointing the exact cause of the “Maven surefire could not find ForkedBooter class” error often requires a systematic approach. Begin by scrutinizing your project’s pom.xml file for any misconfigurations in the surefire plugin. Ensure that the plugin version is compatible with your Java version and other dependencies. Also, check for any explicit forking configurations that might be causing issues. Next, examine the dependency tree to identify potential conflicts. Maven provides tools like mvn dependency:tree to visualize the dependency hierarchy and detect duplicate or conflicting versions of libraries. Pay close attention to the dependencies of the surefire plugin itself, as conflicts in these dependencies can directly lead to the error.

Here is a featured snippet-optimized paragraph. To resolve this error, first verify the Surefire plugin version in your pom.xml file. Update it to the latest stable version compatible with your Java version. Then, clean your Maven project using mvn clean and rebuild it with mvn install. This ensures that all dependencies are correctly resolved and placed in the classpath. If the issue persists, examine your project’s dependency tree for conflicts and exclude any conflicting dependencies. Finally, consider explicitly defining the required dependencies for the Surefire plugin to ensure they are available during test execution.

Consider a scenario where a project uses an older version of the surefire plugin that is not compatible with a newer version of JUnit. This incompatibility can lead to classpath issues and trigger the “ForkedBooter class not found” error. Similarly, in a multi-module project, if one module declares a dependency that conflicts with a dependency declared in another module, the surefire plugin might fail to initialize correctly during test execution. In such cases, explicitly managing the dependencies in the parent pom.xml file or using dependency management features of Maven can help resolve the conflicts and prevent the error. Furthermore, explicitly declaring the maven-surefire-plugin with its dependencies in the pom.xml can sometimes resolve classpath issues, especially in complex projects.

Solutions and Best Practices

Several solutions can effectively address the “Maven surefire could not find ForkedBooter class” error. The most common solution is to explicitly define the version of the maven-surefire-plugin in your pom.xml file. This ensures that a consistent and compatible version of the plugin is used across all builds. Another effective approach is to clean and rebuild your project using the mvn clean install command. This forces Maven to re-resolve all dependencies and rebuild the classpath from scratch, often resolving any transient dependency issues. Furthermore, examining and resolving dependency conflicts through exclusion or version management is crucial for maintaining a stable build environment. Following best practices in dependency management, such as using a bill of materials (BOM) or a dependency management section in the pom.xml, can significantly reduce the likelihood of encountering this error.

Here’s an ordered list of steps to resolve the issue:

Verify Surefire Plugin Version: Ensure you are using a compatible and stable version of the maven-surefire-plugin in your pom.xml. Refer to the Maven documentation for recommended versions.
Clean and Rebuild: Run mvn clean install to clean the project and rebuild it, forcing Maven to re-resolve dependencies.
Check Dependency Tree: Use mvn dependency:tree to identify any conflicting dependencies.
Exclude Conflicting Dependencies: Exclude conflicting dependencies in your pom.xml using the tag.
Explicitly Define Dependencies: Explicitly define the required dependencies for the Surefire plugin to ensure they are available.

Adopting a proactive approach to dependency management is key to preventing this error. Regularly update your dependencies to the latest stable versions, while carefully testing for compatibility issues. Use dependency analysis tools to identify potential conflicts early on. Also, consider using a repository manager like Nexus or Artifactory to centralize dependency management and ensure consistent builds across different environments. By implementing these best practices, you can minimize the risk of encountering the “Maven surefire could not find ForkedBooter class” error and maintain a reliable and efficient build process. Remember, consistent and well-managed dependencies are the cornerstone of a stable Maven project. Robust dependency management is crucial for avoiding unexpected errors.

Advanced Configuration and Customizations

While the basic solutions often resolve the “Maven surefire could not find ForkedBooter class” error, advanced configurations and customizations might be necessary in certain scenarios. For instance, if your project uses custom classloaders or requires specific JVM arguments during test execution, you might need to configure the surefire plugin accordingly. The section of the surefire plugin in your pom.xml file allows you to specify various parameters, such as forkMode, argLine, and classpathDependencyExcludes, to fine-tune the test execution environment. Carefully review the surefire plugin documentation to understand the available configuration options and how they can be used to address specific requirements.

Consider a scenario where your project uses a custom classloader to load certain classes during test execution. In this case, you might need to configure the surefire plugin to use the same classloader in the forked JVM process. This can be achieved by specifying the appropriate argLine parameter in the section of the plugin. Similarly, if your project requires specific JVM arguments, such as memory settings or system properties, you can specify them using the argLine parameter. However, be cautious when customizing the surefire plugin, as incorrect configurations can lead to unexpected behavior or even introduce new errors. Always test your configurations thoroughly to ensure they are working as expected. Baeldung’s guide on Maven Surefire Plugin offers practical examples.

Here are some key points to remember regarding advanced configurations:

Use the section in pom.xml to customize the plugin behavior.
Utilize argLine for specifying JVM arguments and system properties.
Carefully test any customizations to avoid introducing new issues.
Always refer to the official Maven Surefire Plugin documentation for detailed information on available configuration options.
Consider using profiles to manage different configurations for different environments.

Infographic here

FAQ: Maven Surefire and ForkedBooter ------------------------------------

**What does "ForkedBooter" refer to in the Maven Surefire Plugin?**: ForkedBooter is a class within the Maven Surefire Plugin responsible for launching tests in a separate JVM process. This isolation helps prevent interference between tests and the main build process.
**Why is it important to define the Surefire plugin version explicitly?**: Explicitly defining the plugin version ensures consistency across builds and avoids potential compatibility issues with other dependencies in the project. Without a defined version, Maven might use a different version based on its own dependency resolution, which could lead to errors.
**How can I check the dependency tree to identify conflicts?**: Use the command mvn dependency:tree in your terminal. This will print a hierarchical representation of your project's dependencies, making it easier to spot conflicting versions of the same library.
**What is the purpose of the mvn clean install command?**: The mvn clean install command first removes the target directory (where compiled classes and other build artifacts are stored) and then rebuilds the project from scratch. This ensures that all dependencies are re-resolved and that any stale or corrupted files are removed, which can often resolve dependency-related issues.
**Where can I find the official documentation for the Maven Surefire Plugin?**: The official documentation is available on the Apache Maven website: . This documentation provides detailed information on all aspects of the plugin, including configuration options and usage examples.

Resolving the "Maven surefire could not find ForkedBooter class" error requires a methodical approach, combining careful examination of your project's configuration with a solid understanding of Maven's dependency management. By systematically troubleshooting the common causes, implementing the suggested solutions, and adopting best practices, you can overcome this obstacle and ensure the smooth execution of your tests. Remember that a well-configured and consistently managed Maven project is less prone to such errors, leading to faster development cycles and more reliable deployments. Don't let this error slow you down. Take the steps outlined here, and get your builds back on track. Explore topics such as advanced Maven configuration and effective dependency management strategies to further optimize your build process and prevent future issues. [Stack Overflow](https://stackoverflow.com/questions/14748021/maven-surefire-plugin-not-running-junit-tests) offers solutions from other developers.

Question & Answer :
Recently coming to a new project, I’m trying to compile our source code. Everything worked fine yesterday, but today is another story.

Every time I’m running mvn clean install on a module, once reaching the tests, it crashes into an error:

[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ recorder --- [INFO] Surefire report directory: /lhome/code/recorder/target/surefire-reports [INFO] Using configured provider org.apache.maven.surefire.junitcore.JUnitCoreProvider [INFO] parallel='none', perCoreThreadCount=true, threadCount=0, useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0, threadCountMethods=0, parallelOptimized=true ------------------------------------------------------- T E S T S ------------------------------------------------------- Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

and later on:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test (default-test) on project recorder: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test failed: The forked VM terminated without properly saying goodbye. VM crash or System.exit called?

I’m running on Debian 9 (Stretch) 64-bits with OpenJDK 1.8.0_181, Maven 3.5.4, working behind my company proxy which I configured in my ~/.m2/settings.xml.

A strange thing it that the latest Surefire version is 2.22.1 if I remember correctly. I tried to specify the plugin version, but it does not get updated, otherwise there’s no plugin version specification in any POM (parent, grand-parent or this one).

I managed to force Maven to change the Surefire version to the latest, but now it’s even worse:

[INFO] ------------------------------------------------------- [INFO] T E S T S [INFO] ------------------------------------------------------- [INFO] [INFO] Results: [INFO] [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 [...] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.1:test (default-test) on project recorder: There are test failures. [ERROR] [ERROR] Please refer to /lhome/code/recorder/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] The forked VM terminated without properly saying goodbye. VM crash or System.exit called? [ERROR] Command was /bin/sh -c cd /lhome/code/recorder/ && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java '-javaagent:/lhome1/johndoe/.m2/repository/org/jacoco/org.jacoco.agent/0.7.4.201502262128/org.jacoco.agent-0.7.4.201502262128-runt ime.jar=destfile=/lhome/code/recorder/target/jacoco.exec,append=true,includes=esa/*,excludes=**/api/**/*.class' -jar /lhome/code/recorder/target/surefire/surefirebooter7426165516226884923.jar /lhome/code/recorder/target/surefire 2018-10-26T16-16-12_829-jvmRun1 surefire1721866559613511529tmp surefire_023400764142672144tmp [ERROR] Error occurred in starting fork, check output in log [ERROR] Process Exit Code: 1 [ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The forked VM terminated without properly saying goodbye. VM crash or System.exit called? [ERROR] Command was /bin/sh -c cd /lhome/code/recorder/ && /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java '-javaagent:/lhome1/johndoe/.m2/repository/org/jacoco/org.jacoco.agent/0.7.4.201502262128/org.jacoco.agent-0.7.4.201502262128-runt ime.jar=destfile=/lhome/code/recorder/target/jacoco.exec,append=true,includes=esa/*,excludes=**/api/**/*.class' -jar /lhome/code/recorder/target/surefire/surefirebooter7426165516226884923.jar /lhome/code/recorder/target/surefire 2018-10-26T16-16-12_829-jvmRun1 surefire1721866559613511529tmp surefire_023400764142672144tmp [ERROR] Error occurred in starting fork, check output in log [ERROR] Process Exit Code: 1 [ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:669) [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:208) [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154) [ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146) [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:954) [ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) [ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:192) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [ERROR] at java.lang.reflect.Method.invoke(Method.java:498) [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)

To fix it (in 2018), update your openjdk to the latest version, at least 8u191-b12. In case this issue reappears in 2020, it is likely that the default behavior of openjdk was changed, and you will then need to update the maven surefire plugin.

This was a now fixed bug in the openjdk-8 package (behaviour deviates from upstream significantly without need; missing the upstream patch to revert back to disabling a security check) that you just upgraded to. But it is also a bug in the surefire plugin, SUREFIRE-1588, supposedly fixed in surefire 3.0.0-M1: it apparently is using absolute paths in a place where Java will in the future only allow relative path names (and Debian activated the future behavior already).

The package version 8u181-b13-2 states:

Apply patches from 8u191-b12 security update.

Note that 191-b12 != 181-b13. The 191-b12 security patches were just out a few days ago, and apparently the maintainers wanted to get them to you fast. Updating completely to 191-b12 will likely need additional testing (well, so should have this upload, apparently).

There had been several workaounds:

You can install the previous package from snapshots.d.o instead. After downgrading, you can forbid the broken version (if you are using aptitude and not apt) using sudo aptitude forbid-version openjdk-8-jre-headless. For regular “apt” I didn’t see a similar forbid mechanism, so you would likely need to use apt pinning to prevent this upgrade from being reinstalled (or you just keep on downgrading again, I hope this will be resolved soon).
According to bug tracking, setting the property -Djdk.net.URLClassPath.disableClassPathURLCheck=true with any of the usual methods (e.g., JAVA_FLAGS) should also help. But I have not verified this myself. You can apparently even add the workaround to ~/.m2/settings.xml to get it enabled for all your Maven builds easily.

As you can see, bug tracking works, the issue was narrowed down, and a fixed package is available and a new version of the surefire plugin will come soon!