Maven surefire could not find ForkedBooter class










170














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)









share|improve this question



















  • 1




    I'm having this bug in clircle-ci. Surefire forks and forked vm prints the following message and exits: "Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter". The massage is in target/surefire-reports/*.dumpstream . If you run maven with -X it prints the command line, you can try it and see the vm printing this message.
    – Bruno Coutinho
    Oct 26 at 14:54







  • 2




    Possible duplicate of Spring Boot fails to run maven-surefire-plugin ClassNotFoundException org.apache.maven.surefire.booter.ForkedBooter
    – jediz
    Oct 29 at 19:54










  • my solution was to stop using open-jdks of any version. can't afford this kind of unreliability in something so foundational.
    – Adrian M.
    Nov 2 at 20:32










  • Use maven's dependencyManagement section to specify different versions of plugins
    – jogaco
    Nov 9 at 14:08















170














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)









share|improve this question



















  • 1




    I'm having this bug in clircle-ci. Surefire forks and forked vm prints the following message and exits: "Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter". The massage is in target/surefire-reports/*.dumpstream . If you run maven with -X it prints the command line, you can try it and see the vm printing this message.
    – Bruno Coutinho
    Oct 26 at 14:54







  • 2




    Possible duplicate of Spring Boot fails to run maven-surefire-plugin ClassNotFoundException org.apache.maven.surefire.booter.ForkedBooter
    – jediz
    Oct 29 at 19:54










  • my solution was to stop using open-jdks of any version. can't afford this kind of unreliability in something so foundational.
    – Adrian M.
    Nov 2 at 20:32










  • Use maven's dependencyManagement section to specify different versions of plugins
    – jogaco
    Nov 9 at 14:08













170












170








170


35





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)









share|improve this question















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)






java maven maven-surefire-plugin






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 18 at 21:52









Peter Mortensen

13.5k1983111




13.5k1983111










asked Oct 26 at 13:47









Sylordis

1,0472916




1,0472916







  • 1




    I'm having this bug in clircle-ci. Surefire forks and forked vm prints the following message and exits: "Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter". The massage is in target/surefire-reports/*.dumpstream . If you run maven with -X it prints the command line, you can try it and see the vm printing this message.
    – Bruno Coutinho
    Oct 26 at 14:54







  • 2




    Possible duplicate of Spring Boot fails to run maven-surefire-plugin ClassNotFoundException org.apache.maven.surefire.booter.ForkedBooter
    – jediz
    Oct 29 at 19:54










  • my solution was to stop using open-jdks of any version. can't afford this kind of unreliability in something so foundational.
    – Adrian M.
    Nov 2 at 20:32










  • Use maven's dependencyManagement section to specify different versions of plugins
    – jogaco
    Nov 9 at 14:08












  • 1




    I'm having this bug in clircle-ci. Surefire forks and forked vm prints the following message and exits: "Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter". The massage is in target/surefire-reports/*.dumpstream . If you run maven with -X it prints the command line, you can try it and see the vm printing this message.
    – Bruno Coutinho
    Oct 26 at 14:54







  • 2




    Possible duplicate of Spring Boot fails to run maven-surefire-plugin ClassNotFoundException org.apache.maven.surefire.booter.ForkedBooter
    – jediz
    Oct 29 at 19:54










  • my solution was to stop using open-jdks of any version. can't afford this kind of unreliability in something so foundational.
    – Adrian M.
    Nov 2 at 20:32










  • Use maven's dependencyManagement section to specify different versions of plugins
    – jogaco
    Nov 9 at 14:08







1




1




I'm having this bug in clircle-ci. Surefire forks and forked vm prints the following message and exits: "Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter". The massage is in target/surefire-reports/*.dumpstream . If you run maven with -X it prints the command line, you can try it and see the vm printing this message.
– Bruno Coutinho
Oct 26 at 14:54





I'm having this bug in clircle-ci. Surefire forks and forked vm prints the following message and exits: "Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter". The massage is in target/surefire-reports/*.dumpstream . If you run maven with -X it prints the command line, you can try it and see the vm printing this message.
– Bruno Coutinho
Oct 26 at 14:54





2




2




Possible duplicate of Spring Boot fails to run maven-surefire-plugin ClassNotFoundException org.apache.maven.surefire.booter.ForkedBooter
– jediz
Oct 29 at 19:54




Possible duplicate of Spring Boot fails to run maven-surefire-plugin ClassNotFoundException org.apache.maven.surefire.booter.ForkedBooter
– jediz
Oct 29 at 19:54












my solution was to stop using open-jdks of any version. can't afford this kind of unreliability in something so foundational.
– Adrian M.
Nov 2 at 20:32




my solution was to stop using open-jdks of any version. can't afford this kind of unreliability in something so foundational.
– Adrian M.
Nov 2 at 20:32












Use maven's dependencyManagement section to specify different versions of plugins
– jogaco
Nov 9 at 14:08




Use maven's dependencyManagement section to specify different versions of plugins
– jogaco
Nov 9 at 14:08












15 Answers
15






active

oldest

votes


















198














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:



  1. 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).

  2. 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!






share|improve this answer


















  • 1




    I just got the same issue on Ubuntu 18.04, using OpenJDK 10.0.2. Switching the JAVA_HOME to my 'java-9-oracle' install fixed it.
    – RobAu
    Oct 31 at 8:36






  • 2




    Here’s the corresponding issue in the surefire-maven-plugin issue tracker: issues.apache.org/jira/browse/SUREFIRE-1588 (it’s still a bug in the Canonical/Debian backport of the relevant OpenJDK changes).
    – mirabilos
    Oct 31 at 13:14






  • 1




    Work around 1. doesn't make sense to me as that's the version I'm experiencing the issue on. Overriding the maven-surefire-plugin to not useSystemClassLoader also didn't work
    – Edwin Diaz-Mendez
    Nov 1 at 22:18






  • 2




    Verified that workaround 2 works. Thanks for the detailed answer!
    – Bernie
    Nov 2 at 3:45






  • 1




    You can try upgrading to surefire 3.0.0-M1, too. But 2 to a 3 milestone version can of course break other stuff.
    – Erich Schubert
    Nov 8 at 16:34


















46














I found this workaround and fixed my tests: configure the maven-surefire-plugin not to use the system classloader.






share|improve this answer






















  • According to the maven-surefire-plugin maintainer, all workarounds (this, setting forkCount to 0, or setting argLine globally) have problems and cannot be applied universally.
    – mirabilos
    Nov 2 at 13:16










  • Good find. But please include the actual workaround text in your post, or at least identify the link clearly as a stackoverflow link. I.e. the approach used by @markoorn is more helpful.
    – nealmcb
    Nov 12 at 19:20










  • @nealmcb, second that, currently the answer look very-very low quality.
    – user28434
    Nov 14 at 14:35


















40














Set useSystemClassloader to false:



<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
</configuration>
</plugin>


If you're not inheriting from a parent which has version defined for you (such as the Spring Boot starter) you'll need to define that as well.






share|improve this answer






















  • this is litterally stackoverflow.com/a/53012553/1467837
    – Sylordis
    Nov 1 at 10:03










  • This fixed it for me! We are using maven-surefire-plugin v2.14.1
    – Chris F
    Nov 7 at 2:16










  • Very helpful - worked for me. But for us noobs, I appreciate even more the approach by @ArunTracer noting how to include this in pom.xml :)
    – nealmcb
    Nov 12 at 19:23


















34














I have another workaround. Set the environment variable _JAVA_OPTIONS. I've used this for our TeamCity build agents and now our builds run fine.



_JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true





share|improve this answer
















  • 1




    I prefer this answer than the ones that require modification to the project's source (POM)
    – George Aristy
    Nov 4 at 15:30






  • 1




    This one works perfectly! Good workaround until the problem is fixed and as @GeorgeAristy mentions a better options than changing pom files.
    – froginvasion
    Nov 8 at 8:26










  • A breaking change labelled as a security fix is usually not introduced for no reason and so that someone tells on SO how to disable it... just sayin'
    – berezovskyi
    Nov 28 at 15:41


















25














I posted a more targeted variant of one of the above workarounds in JIRA. Add to ~/.m2/settings.xml:



<profile>
<id>SUREFIRE-1588</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<properties>
<argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
</properties>
</profile>





share|improve this answer




















  • Excellent workaround with global effect.
    – Wolfgang Fahl
    Nov 2 at 11:21










  • This fails with the following warning: [WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9) @ /home/nikolai/.m2/settings.xml, line 1, column 9
    – Nikolai
    Nov 11 at 14:02






  • 2




    @Nikolai The above snippet needs to be enclosed in <settings><profiles>...</profiles></settings>.
    – qqx
    Nov 12 at 21:23


















7














I had this issue in my GitLab CI build, which was using maven:3.5.4-jdk-8 Docker image.



Changing it to maven:3.5.4-jdk-8-alpine fixed the problem.






share|improve this answer




























    6














    I followed this link https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html and added the below plugin in pom.xml and it worked,



    <project>
    [...]
    <build>
    <plugins>
    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.22.1</version>
    <configuration>
    <useSystemClassLoader>false</useSystemClassLoader>
    </configuration>
    </plugin>
    </plugins>
    </build>
    [...]
    </project>





    share|improve this answer




























      4














      The suggestion above to set the property "-Djdk.net.URLClassPath.disableClassPathURLCheck=true" did NOT work for me, but setting the following does work OK:



      -DforkCount=0





      share|improve this answer


















      • 2




        This has the effect of not creating a new VM for running the tests, so the tests can possibly influence the main build VM.
        – Paŭlo Ebermann
        Nov 6 at 10:25


















      4














      For Ubuntu: Install the latest version, it has this bug fixed



      sudo apt-get update ; sudo apt-get dist-upgrade -y


      Install the last working version (without security patches) without the bug.



      sudo apt-get install openjdk-8-jdk-headless=8u181-b13-1 openjdk-8-jdk=8u181-b13-1 openjdk-8-jre=8u181-b13-1 openjdk-8-jre-headless=8u181-b13-1 openjdk-8-source=8u181-b13-1


      If you missed that version, use the version before that:



      sudo apt-get install openjdk-8-jdk-headless=8u162-b12-1 openjdk-8-jdk=8u162-b12-1 openjdk-8-jre=8u162-b12-1 openjdk-8-jre-headless=8u162-b12-1 openjdk-8-source=8u162-b12-1


      Then use either pinning or watch out that you won't install the broken version.



      Using -Djdk.net.URLClassPath.disableClassPathURLCheck=true didn't work for me wherever I had put that configuration. Somewhere in my integration-tests it always exited without the old Java version.



      As mentioned by Erich it's a bug in the Debian package being too strict 911925 and the Surefire-plugin not acting according to the new rules SUREFIRE-1588.






      share|improve this answer






















      • Why would anyone suggest to install a version without security patches?! Though other suggestions include skipping tests, huh.
        – berezovskyi
        Nov 28 at 15:43






      • 1




        You don't need to anymore :-) It's fixed. But for the meantime I had many java projects which I had to work on and my java runtime was nowhere exposed to any new code from outside. So there was a oversee-able risk that was Ok for me. It's everyone's own decision after all :-)
        – flob
        Nov 28 at 15:58










      • Actually you are right, I found that JDK devs walked back on that prop set by default: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8; but major version upgrade to surefire does not seem like the best fix to me, actually.
        – berezovskyi
        Nov 28 at 15:59







      • 1




        Absolutely! But the changes they had to make are throughout the whole codebase and very invasive. So a minor version change for this fix wouldn't be an option in surefire.
        – flob
        Nov 28 at 16:04






      • 1




        And unfortunately, 2.x is discontinued and we'll have to make a switch sooner than later: issues.apache.org/jira/browse/…
        – berezovskyi
        Nov 28 at 16:05


















      3














      For those searching for an answer related to Docker Maven: 3.5.x-jdk-8 on GitLab CI, see this GitHub issue.



      It appears a 3.5.4-jdk-8 image resulted in upgrade to a minor Java version which somehow affects Surefire's forking mechanism.



      Rolling back to 3.5.3-jdk-8 image fixed this for me on my GitLab CI server building Java 1.8 code with Surefire 2.20.1.






      share|improve this answer






























        1














        I recently setup maven job on Jenkins and got stuck into the same problem. I took the suggestion to modify the JAVA env variable and confirm the issue resolved. This is how I tested.



        Becomes "jenkins" user and change folder to workspace project name that you setup for the job.



         $ _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true mvn clean install -U

        $ lsb_release -rd
        Description: Ubuntu 16.04.5 LTS
        Release: 16.04

        $ mvn -v
        Apache Maven 3.3.9
        Maven home: /usr/share/maven
        Java version: 1.8.0_181, vendor: Oracle Corporation
        Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
        Default locale: en_US, platform encoding: UTF-8
        OS name: "linux", version: "4.4.0-131-generic", arch: "amd64", family: "unix"





        share|improve this answer






























          0














          I uninstalled the JDK that comes in the repositories:



          $ sudo apt purge openjdk-8-jdk

          $ sudo apt autoremove


          Then I deleted the JAVA_HOME environment variable. Mine was set in my .bashrc.



          Then I reinstalled it through SDKMAN:



          $ sdk install java 8.0.181-zulu


          From their site:




          SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems. It provides a convenient Command Line Interface (CLI) and API for installing, switching, removing and listing Candidates.




          To see other versions of the JDK to install, use:



          $ sdk list java





          share|improve this answer






























            0














            I was facing the same issue with gitlab ci, changing maven image from maven:3-jdk-8 to maven:3.6.0-jdk-8-alpine seems to fix the issue. Btw I also tested with maven:3.6.0-jdk-8 but it didn't work neither.






            share|improve this answer




























              -1














              I am used as this as workaround to stop the compilation and execution of test files:



              -Dmaven.test.skip=true with maven





              share|improve this answer


















              • 3




                why would one want to skip the tests?
                – Syed Mauze Rehan
                Nov 21 at 10:42










              • It’s like you’re answering a different question?
                – Ole V.V.
                Dec 18 at 18:31


















              -2














              If like me you have issues in your pipeline (for me it's in GitLab, but whatever) and if you are using a Maven JDK 8 Docker image.



              You can replace



              image: maven:3.5.4-jdk-8


              by the last working build



              image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b





              share|improve this answer


















              • 1




                The problem comes from the latest jdk8 for debian, In my opinion it's better to "fix" the core problem than to try to work around it.
                – Sylordis
                Oct 31 at 16:32










              • The sha256 sound tricky and afraid you ? Actually other answer looks more like a work around, disable some feature from surefire, here it's just about use the last working docker image without changing your working pom or pipeline which is a work around.
                – amdev
                Nov 2 at 8:21










              Your Answer






              StackExchange.ifUsing("editor", function ()
              StackExchange.using("externalEditor", function ()
              StackExchange.using("snippets", function ()
              StackExchange.snippets.init();
              );
              );
              , "code-snippets");

              StackExchange.ready(function()
              var channelOptions =
              tags: "".split(" "),
              id: "1"
              ;
              initTagRenderer("".split(" "), "".split(" "), channelOptions);

              StackExchange.using("externalEditor", function()
              // Have to fire editor after snippets, if snippets enabled
              if (StackExchange.settings.snippets.snippetsEnabled)
              StackExchange.using("snippets", function()
              createEditor();
              );

              else
              createEditor();

              );

              function createEditor()
              StackExchange.prepareEditor(
              heartbeatType: 'answer',
              autoActivateHeartbeat: false,
              convertImagesToLinks: true,
              noModals: true,
              showLowRepImageUploadWarning: true,
              reputationToPostImages: 10,
              bindNavPrevention: true,
              postfix: "",
              imageUploader:
              brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
              contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
              allowUrls: true
              ,
              onDemand: true,
              discardSelector: ".discard-answer"
              ,immediatelyShowMarkdownHelp:true
              );



              );













              draft saved

              draft discarded


















              StackExchange.ready(
              function ()
              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53010200%2fmaven-surefire-could-not-find-forkedbooter-class%23new-answer', 'question_page');

              );

              Post as a guest















              Required, but never shown

























              15 Answers
              15






              active

              oldest

              votes








              15 Answers
              15






              active

              oldest

              votes









              active

              oldest

              votes






              active

              oldest

              votes









              198














              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:



              1. 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).

              2. 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!






              share|improve this answer


















              • 1




                I just got the same issue on Ubuntu 18.04, using OpenJDK 10.0.2. Switching the JAVA_HOME to my 'java-9-oracle' install fixed it.
                – RobAu
                Oct 31 at 8:36






              • 2




                Here’s the corresponding issue in the surefire-maven-plugin issue tracker: issues.apache.org/jira/browse/SUREFIRE-1588 (it’s still a bug in the Canonical/Debian backport of the relevant OpenJDK changes).
                – mirabilos
                Oct 31 at 13:14






              • 1




                Work around 1. doesn't make sense to me as that's the version I'm experiencing the issue on. Overriding the maven-surefire-plugin to not useSystemClassLoader also didn't work
                – Edwin Diaz-Mendez
                Nov 1 at 22:18






              • 2




                Verified that workaround 2 works. Thanks for the detailed answer!
                – Bernie
                Nov 2 at 3:45






              • 1




                You can try upgrading to surefire 3.0.0-M1, too. But 2 to a 3 milestone version can of course break other stuff.
                – Erich Schubert
                Nov 8 at 16:34















              198














              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:



              1. 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).

              2. 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!






              share|improve this answer


















              • 1




                I just got the same issue on Ubuntu 18.04, using OpenJDK 10.0.2. Switching the JAVA_HOME to my 'java-9-oracle' install fixed it.
                – RobAu
                Oct 31 at 8:36






              • 2




                Here’s the corresponding issue in the surefire-maven-plugin issue tracker: issues.apache.org/jira/browse/SUREFIRE-1588 (it’s still a bug in the Canonical/Debian backport of the relevant OpenJDK changes).
                – mirabilos
                Oct 31 at 13:14






              • 1




                Work around 1. doesn't make sense to me as that's the version I'm experiencing the issue on. Overriding the maven-surefire-plugin to not useSystemClassLoader also didn't work
                – Edwin Diaz-Mendez
                Nov 1 at 22:18






              • 2




                Verified that workaround 2 works. Thanks for the detailed answer!
                – Bernie
                Nov 2 at 3:45






              • 1




                You can try upgrading to surefire 3.0.0-M1, too. But 2 to a 3 milestone version can of course break other stuff.
                – Erich Schubert
                Nov 8 at 16:34













              198












              198








              198






              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:



              1. 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).

              2. 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!






              share|improve this answer














              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:



              1. 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).

              2. 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!







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Dec 8 at 19:52

























              answered Oct 26 at 21:30









              Erich Schubert

              6,78411737




              6,78411737







              • 1




                I just got the same issue on Ubuntu 18.04, using OpenJDK 10.0.2. Switching the JAVA_HOME to my 'java-9-oracle' install fixed it.
                – RobAu
                Oct 31 at 8:36






              • 2




                Here’s the corresponding issue in the surefire-maven-plugin issue tracker: issues.apache.org/jira/browse/SUREFIRE-1588 (it’s still a bug in the Canonical/Debian backport of the relevant OpenJDK changes).
                – mirabilos
                Oct 31 at 13:14






              • 1




                Work around 1. doesn't make sense to me as that's the version I'm experiencing the issue on. Overriding the maven-surefire-plugin to not useSystemClassLoader also didn't work
                – Edwin Diaz-Mendez
                Nov 1 at 22:18






              • 2




                Verified that workaround 2 works. Thanks for the detailed answer!
                – Bernie
                Nov 2 at 3:45






              • 1




                You can try upgrading to surefire 3.0.0-M1, too. But 2 to a 3 milestone version can of course break other stuff.
                – Erich Schubert
                Nov 8 at 16:34












              • 1




                I just got the same issue on Ubuntu 18.04, using OpenJDK 10.0.2. Switching the JAVA_HOME to my 'java-9-oracle' install fixed it.
                – RobAu
                Oct 31 at 8:36






              • 2




                Here’s the corresponding issue in the surefire-maven-plugin issue tracker: issues.apache.org/jira/browse/SUREFIRE-1588 (it’s still a bug in the Canonical/Debian backport of the relevant OpenJDK changes).
                – mirabilos
                Oct 31 at 13:14






              • 1




                Work around 1. doesn't make sense to me as that's the version I'm experiencing the issue on. Overriding the maven-surefire-plugin to not useSystemClassLoader also didn't work
                – Edwin Diaz-Mendez
                Nov 1 at 22:18






              • 2




                Verified that workaround 2 works. Thanks for the detailed answer!
                – Bernie
                Nov 2 at 3:45






              • 1




                You can try upgrading to surefire 3.0.0-M1, too. But 2 to a 3 milestone version can of course break other stuff.
                – Erich Schubert
                Nov 8 at 16:34







              1




              1




              I just got the same issue on Ubuntu 18.04, using OpenJDK 10.0.2. Switching the JAVA_HOME to my 'java-9-oracle' install fixed it.
              – RobAu
              Oct 31 at 8:36




              I just got the same issue on Ubuntu 18.04, using OpenJDK 10.0.2. Switching the JAVA_HOME to my 'java-9-oracle' install fixed it.
              – RobAu
              Oct 31 at 8:36




              2




              2




              Here’s the corresponding issue in the surefire-maven-plugin issue tracker: issues.apache.org/jira/browse/SUREFIRE-1588 (it’s still a bug in the Canonical/Debian backport of the relevant OpenJDK changes).
              – mirabilos
              Oct 31 at 13:14




              Here’s the corresponding issue in the surefire-maven-plugin issue tracker: issues.apache.org/jira/browse/SUREFIRE-1588 (it’s still a bug in the Canonical/Debian backport of the relevant OpenJDK changes).
              – mirabilos
              Oct 31 at 13:14




              1




              1




              Work around 1. doesn't make sense to me as that's the version I'm experiencing the issue on. Overriding the maven-surefire-plugin to not useSystemClassLoader also didn't work
              – Edwin Diaz-Mendez
              Nov 1 at 22:18




              Work around 1. doesn't make sense to me as that's the version I'm experiencing the issue on. Overriding the maven-surefire-plugin to not useSystemClassLoader also didn't work
              – Edwin Diaz-Mendez
              Nov 1 at 22:18




              2




              2




              Verified that workaround 2 works. Thanks for the detailed answer!
              – Bernie
              Nov 2 at 3:45




              Verified that workaround 2 works. Thanks for the detailed answer!
              – Bernie
              Nov 2 at 3:45




              1




              1




              You can try upgrading to surefire 3.0.0-M1, too. But 2 to a 3 milestone version can of course break other stuff.
              – Erich Schubert
              Nov 8 at 16:34




              You can try upgrading to surefire 3.0.0-M1, too. But 2 to a 3 milestone version can of course break other stuff.
              – Erich Schubert
              Nov 8 at 16:34













              46














              I found this workaround and fixed my tests: configure the maven-surefire-plugin not to use the system classloader.






              share|improve this answer






















              • According to the maven-surefire-plugin maintainer, all workarounds (this, setting forkCount to 0, or setting argLine globally) have problems and cannot be applied universally.
                – mirabilos
                Nov 2 at 13:16










              • Good find. But please include the actual workaround text in your post, or at least identify the link clearly as a stackoverflow link. I.e. the approach used by @markoorn is more helpful.
                – nealmcb
                Nov 12 at 19:20










              • @nealmcb, second that, currently the answer look very-very low quality.
                – user28434
                Nov 14 at 14:35















              46














              I found this workaround and fixed my tests: configure the maven-surefire-plugin not to use the system classloader.






              share|improve this answer






















              • According to the maven-surefire-plugin maintainer, all workarounds (this, setting forkCount to 0, or setting argLine globally) have problems and cannot be applied universally.
                – mirabilos
                Nov 2 at 13:16










              • Good find. But please include the actual workaround text in your post, or at least identify the link clearly as a stackoverflow link. I.e. the approach used by @markoorn is more helpful.
                – nealmcb
                Nov 12 at 19:20










              • @nealmcb, second that, currently the answer look very-very low quality.
                – user28434
                Nov 14 at 14:35













              46












              46








              46






              I found this workaround and fixed my tests: configure the maven-surefire-plugin not to use the system classloader.






              share|improve this answer














              I found this workaround and fixed my tests: configure the maven-surefire-plugin not to use the system classloader.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Oct 31 at 13:43









              Raedwald

              25.8k2295155




              25.8k2295155










              answered Oct 26 at 16:06









              user3090935

              49333




              49333











              • According to the maven-surefire-plugin maintainer, all workarounds (this, setting forkCount to 0, or setting argLine globally) have problems and cannot be applied universally.
                – mirabilos
                Nov 2 at 13:16










              • Good find. But please include the actual workaround text in your post, or at least identify the link clearly as a stackoverflow link. I.e. the approach used by @markoorn is more helpful.
                – nealmcb
                Nov 12 at 19:20










              • @nealmcb, second that, currently the answer look very-very low quality.
                – user28434
                Nov 14 at 14:35
















              • According to the maven-surefire-plugin maintainer, all workarounds (this, setting forkCount to 0, or setting argLine globally) have problems and cannot be applied universally.
                – mirabilos
                Nov 2 at 13:16










              • Good find. But please include the actual workaround text in your post, or at least identify the link clearly as a stackoverflow link. I.e. the approach used by @markoorn is more helpful.
                – nealmcb
                Nov 12 at 19:20










              • @nealmcb, second that, currently the answer look very-very low quality.
                – user28434
                Nov 14 at 14:35















              According to the maven-surefire-plugin maintainer, all workarounds (this, setting forkCount to 0, or setting argLine globally) have problems and cannot be applied universally.
              – mirabilos
              Nov 2 at 13:16




              According to the maven-surefire-plugin maintainer, all workarounds (this, setting forkCount to 0, or setting argLine globally) have problems and cannot be applied universally.
              – mirabilos
              Nov 2 at 13:16












              Good find. But please include the actual workaround text in your post, or at least identify the link clearly as a stackoverflow link. I.e. the approach used by @markoorn is more helpful.
              – nealmcb
              Nov 12 at 19:20




              Good find. But please include the actual workaround text in your post, or at least identify the link clearly as a stackoverflow link. I.e. the approach used by @markoorn is more helpful.
              – nealmcb
              Nov 12 at 19:20












              @nealmcb, second that, currently the answer look very-very low quality.
              – user28434
              Nov 14 at 14:35




              @nealmcb, second that, currently the answer look very-very low quality.
              – user28434
              Nov 14 at 14:35











              40














              Set useSystemClassloader to false:



              <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-surefire-plugin</artifactId>
              <configuration>
              <useSystemClassLoader>false</useSystemClassLoader>
              </configuration>
              </plugin>


              If you're not inheriting from a parent which has version defined for you (such as the Spring Boot starter) you'll need to define that as well.






              share|improve this answer






















              • this is litterally stackoverflow.com/a/53012553/1467837
                – Sylordis
                Nov 1 at 10:03










              • This fixed it for me! We are using maven-surefire-plugin v2.14.1
                – Chris F
                Nov 7 at 2:16










              • Very helpful - worked for me. But for us noobs, I appreciate even more the approach by @ArunTracer noting how to include this in pom.xml :)
                – nealmcb
                Nov 12 at 19:23















              40














              Set useSystemClassloader to false:



              <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-surefire-plugin</artifactId>
              <configuration>
              <useSystemClassLoader>false</useSystemClassLoader>
              </configuration>
              </plugin>


              If you're not inheriting from a parent which has version defined for you (such as the Spring Boot starter) you'll need to define that as well.






              share|improve this answer






















              • this is litterally stackoverflow.com/a/53012553/1467837
                – Sylordis
                Nov 1 at 10:03










              • This fixed it for me! We are using maven-surefire-plugin v2.14.1
                – Chris F
                Nov 7 at 2:16










              • Very helpful - worked for me. But for us noobs, I appreciate even more the approach by @ArunTracer noting how to include this in pom.xml :)
                – nealmcb
                Nov 12 at 19:23













              40












              40








              40






              Set useSystemClassloader to false:



              <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-surefire-plugin</artifactId>
              <configuration>
              <useSystemClassLoader>false</useSystemClassLoader>
              </configuration>
              </plugin>


              If you're not inheriting from a parent which has version defined for you (such as the Spring Boot starter) you'll need to define that as well.






              share|improve this answer














              Set useSystemClassloader to false:



              <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-surefire-plugin</artifactId>
              <configuration>
              <useSystemClassLoader>false</useSystemClassLoader>
              </configuration>
              </plugin>


              If you're not inheriting from a parent which has version defined for you (such as the Spring Boot starter) you'll need to define that as well.







              share|improve this answer














              share|improve this answer



              share|improve this answer








              edited Nov 18 at 21:58









              Peter Mortensen

              13.5k1983111




              13.5k1983111










              answered Nov 1 at 6:26









              Markoorn

              857614




              857614











              • this is litterally stackoverflow.com/a/53012553/1467837
                – Sylordis
                Nov 1 at 10:03










              • This fixed it for me! We are using maven-surefire-plugin v2.14.1
                – Chris F
                Nov 7 at 2:16










              • Very helpful - worked for me. But for us noobs, I appreciate even more the approach by @ArunTracer noting how to include this in pom.xml :)
                – nealmcb
                Nov 12 at 19:23
















              • this is litterally stackoverflow.com/a/53012553/1467837
                – Sylordis
                Nov 1 at 10:03










              • This fixed it for me! We are using maven-surefire-plugin v2.14.1
                – Chris F
                Nov 7 at 2:16










              • Very helpful - worked for me. But for us noobs, I appreciate even more the approach by @ArunTracer noting how to include this in pom.xml :)
                – nealmcb
                Nov 12 at 19:23















              this is litterally stackoverflow.com/a/53012553/1467837
              – Sylordis
              Nov 1 at 10:03




              this is litterally stackoverflow.com/a/53012553/1467837
              – Sylordis
              Nov 1 at 10:03












              This fixed it for me! We are using maven-surefire-plugin v2.14.1
              – Chris F
              Nov 7 at 2:16




              This fixed it for me! We are using maven-surefire-plugin v2.14.1
              – Chris F
              Nov 7 at 2:16












              Very helpful - worked for me. But for us noobs, I appreciate even more the approach by @ArunTracer noting how to include this in pom.xml :)
              – nealmcb
              Nov 12 at 19:23




              Very helpful - worked for me. But for us noobs, I appreciate even more the approach by @ArunTracer noting how to include this in pom.xml :)
              – nealmcb
              Nov 12 at 19:23











              34














              I have another workaround. Set the environment variable _JAVA_OPTIONS. I've used this for our TeamCity build agents and now our builds run fine.



              _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true





              share|improve this answer
















              • 1




                I prefer this answer than the ones that require modification to the project's source (POM)
                – George Aristy
                Nov 4 at 15:30






              • 1




                This one works perfectly! Good workaround until the problem is fixed and as @GeorgeAristy mentions a better options than changing pom files.
                – froginvasion
                Nov 8 at 8:26










              • A breaking change labelled as a security fix is usually not introduced for no reason and so that someone tells on SO how to disable it... just sayin'
                – berezovskyi
                Nov 28 at 15:41















              34














              I have another workaround. Set the environment variable _JAVA_OPTIONS. I've used this for our TeamCity build agents and now our builds run fine.



              _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true





              share|improve this answer
















              • 1




                I prefer this answer than the ones that require modification to the project's source (POM)
                – George Aristy
                Nov 4 at 15:30






              • 1




                This one works perfectly! Good workaround until the problem is fixed and as @GeorgeAristy mentions a better options than changing pom files.
                – froginvasion
                Nov 8 at 8:26










              • A breaking change labelled as a security fix is usually not introduced for no reason and so that someone tells on SO how to disable it... just sayin'
                – berezovskyi
                Nov 28 at 15:41













              34












              34








              34






              I have another workaround. Set the environment variable _JAVA_OPTIONS. I've used this for our TeamCity build agents and now our builds run fine.



              _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true





              share|improve this answer












              I have another workaround. Set the environment variable _JAVA_OPTIONS. I've used this for our TeamCity build agents and now our builds run fine.



              _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true






              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Oct 31 at 14:31









              Michael

              37623




              37623







              • 1




                I prefer this answer than the ones that require modification to the project's source (POM)
                – George Aristy
                Nov 4 at 15:30






              • 1




                This one works perfectly! Good workaround until the problem is fixed and as @GeorgeAristy mentions a better options than changing pom files.
                – froginvasion
                Nov 8 at 8:26










              • A breaking change labelled as a security fix is usually not introduced for no reason and so that someone tells on SO how to disable it... just sayin'
                – berezovskyi
                Nov 28 at 15:41












              • 1




                I prefer this answer than the ones that require modification to the project's source (POM)
                – George Aristy
                Nov 4 at 15:30






              • 1




                This one works perfectly! Good workaround until the problem is fixed and as @GeorgeAristy mentions a better options than changing pom files.
                – froginvasion
                Nov 8 at 8:26










              • A breaking change labelled as a security fix is usually not introduced for no reason and so that someone tells on SO how to disable it... just sayin'
                – berezovskyi
                Nov 28 at 15:41







              1




              1




              I prefer this answer than the ones that require modification to the project's source (POM)
              – George Aristy
              Nov 4 at 15:30




              I prefer this answer than the ones that require modification to the project's source (POM)
              – George Aristy
              Nov 4 at 15:30




              1




              1




              This one works perfectly! Good workaround until the problem is fixed and as @GeorgeAristy mentions a better options than changing pom files.
              – froginvasion
              Nov 8 at 8:26




              This one works perfectly! Good workaround until the problem is fixed and as @GeorgeAristy mentions a better options than changing pom files.
              – froginvasion
              Nov 8 at 8:26












              A breaking change labelled as a security fix is usually not introduced for no reason and so that someone tells on SO how to disable it... just sayin'
              – berezovskyi
              Nov 28 at 15:41




              A breaking change labelled as a security fix is usually not introduced for no reason and so that someone tells on SO how to disable it... just sayin'
              – berezovskyi
              Nov 28 at 15:41











              25














              I posted a more targeted variant of one of the above workarounds in JIRA. Add to ~/.m2/settings.xml:



              <profile>
              <id>SUREFIRE-1588</id>
              <activation>
              <activeByDefault>true</activeByDefault>
              </activation>
              <properties>
              <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
              </properties>
              </profile>





              share|improve this answer




















              • Excellent workaround with global effect.
                – Wolfgang Fahl
                Nov 2 at 11:21










              • This fails with the following warning: [WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9) @ /home/nikolai/.m2/settings.xml, line 1, column 9
                – Nikolai
                Nov 11 at 14:02






              • 2




                @Nikolai The above snippet needs to be enclosed in <settings><profiles>...</profiles></settings>.
                – qqx
                Nov 12 at 21:23















              25














              I posted a more targeted variant of one of the above workarounds in JIRA. Add to ~/.m2/settings.xml:



              <profile>
              <id>SUREFIRE-1588</id>
              <activation>
              <activeByDefault>true</activeByDefault>
              </activation>
              <properties>
              <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
              </properties>
              </profile>





              share|improve this answer




















              • Excellent workaround with global effect.
                – Wolfgang Fahl
                Nov 2 at 11:21










              • This fails with the following warning: [WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9) @ /home/nikolai/.m2/settings.xml, line 1, column 9
                – Nikolai
                Nov 11 at 14:02






              • 2




                @Nikolai The above snippet needs to be enclosed in <settings><profiles>...</profiles></settings>.
                – qqx
                Nov 12 at 21:23













              25












              25








              25






              I posted a more targeted variant of one of the above workarounds in JIRA. Add to ~/.m2/settings.xml:



              <profile>
              <id>SUREFIRE-1588</id>
              <activation>
              <activeByDefault>true</activeByDefault>
              </activation>
              <properties>
              <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
              </properties>
              </profile>





              share|improve this answer












              I posted a more targeted variant of one of the above workarounds in JIRA. Add to ~/.m2/settings.xml:



              <profile>
              <id>SUREFIRE-1588</id>
              <activation>
              <activeByDefault>true</activeByDefault>
              </activation>
              <properties>
              <argLine>-Djdk.net.URLClassPath.disableClassPathURLCheck=true</argLine>
              </properties>
              </profile>






              share|improve this answer












              share|improve this answer



              share|improve this answer










              answered Nov 1 at 16:05









              Jesse Glick

              16.3k36287




              16.3k36287











              • Excellent workaround with global effect.
                – Wolfgang Fahl
                Nov 2 at 11:21










              • This fails with the following warning: [WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9) @ /home/nikolai/.m2/settings.xml, line 1, column 9
                – Nikolai
                Nov 11 at 14:02






              • 2




                @Nikolai The above snippet needs to be enclosed in <settings><profiles>...</profiles></settings>.
                – qqx
                Nov 12 at 21:23
















              • Excellent workaround with global effect.
                – Wolfgang Fahl
                Nov 2 at 11:21










              • This fails with the following warning: [WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9) @ /home/nikolai/.m2/settings.xml, line 1, column 9
                – Nikolai
                Nov 11 at 14:02






              • 2




                @Nikolai The above snippet needs to be enclosed in <settings><profiles>...</profiles></settings>.
                – qqx
                Nov 12 at 21:23















              Excellent workaround with global effect.
              – Wolfgang Fahl
              Nov 2 at 11:21




              Excellent workaround with global effect.
              – Wolfgang Fahl
              Nov 2 at 11:21












              This fails with the following warning: [WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9) @ /home/nikolai/.m2/settings.xml, line 1, column 9
              – Nikolai
              Nov 11 at 14:02




              This fails with the following warning: [WARNING] Expected root element 'settings' but found 'profile' (position: START_TAG seen <profile>... @1:9) @ /home/nikolai/.m2/settings.xml, line 1, column 9
              – Nikolai
              Nov 11 at 14:02




              2




              2




              @Nikolai The above snippet needs to be enclosed in <settings><profiles>...</profiles></settings>.
              – qqx
              Nov 12 at 21:23




              @Nikolai The above snippet needs to be enclosed in <settings><profiles>...</profiles></settings>.
              – qqx
              Nov 12 at 21:23











              7














              I had this issue in my GitLab CI build, which was using maven:3.5.4-jdk-8 Docker image.



              Changing it to maven:3.5.4-jdk-8-alpine fixed the problem.






              share|improve this answer

























                7














                I had this issue in my GitLab CI build, which was using maven:3.5.4-jdk-8 Docker image.



                Changing it to maven:3.5.4-jdk-8-alpine fixed the problem.






                share|improve this answer























                  7












                  7








                  7






                  I had this issue in my GitLab CI build, which was using maven:3.5.4-jdk-8 Docker image.



                  Changing it to maven:3.5.4-jdk-8-alpine fixed the problem.






                  share|improve this answer












                  I had this issue in my GitLab CI build, which was using maven:3.5.4-jdk-8 Docker image.



                  Changing it to maven:3.5.4-jdk-8-alpine fixed the problem.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Oct 30 at 16:31









                  brunobastosg

                  737918




                  737918





















                      6














                      I followed this link https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html and added the below plugin in pom.xml and it worked,



                      <project>
                      [...]
                      <build>
                      <plugins>
                      <plugin>
                      <groupId>org.apache.maven.plugins</groupId>
                      <artifactId>maven-surefire-plugin</artifactId>
                      <version>2.22.1</version>
                      <configuration>
                      <useSystemClassLoader>false</useSystemClassLoader>
                      </configuration>
                      </plugin>
                      </plugins>
                      </build>
                      [...]
                      </project>





                      share|improve this answer

























                        6














                        I followed this link https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html and added the below plugin in pom.xml and it worked,



                        <project>
                        [...]
                        <build>
                        <plugins>
                        <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <version>2.22.1</version>
                        <configuration>
                        <useSystemClassLoader>false</useSystemClassLoader>
                        </configuration>
                        </plugin>
                        </plugins>
                        </build>
                        [...]
                        </project>





                        share|improve this answer























                          6












                          6








                          6






                          I followed this link https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html and added the below plugin in pom.xml and it worked,



                          <project>
                          [...]
                          <build>
                          <plugins>
                          <plugin>
                          <groupId>org.apache.maven.plugins</groupId>
                          <artifactId>maven-surefire-plugin</artifactId>
                          <version>2.22.1</version>
                          <configuration>
                          <useSystemClassLoader>false</useSystemClassLoader>
                          </configuration>
                          </plugin>
                          </plugins>
                          </build>
                          [...]
                          </project>





                          share|improve this answer












                          I followed this link https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html and added the below plugin in pom.xml and it worked,



                          <project>
                          [...]
                          <build>
                          <plugins>
                          <plugin>
                          <groupId>org.apache.maven.plugins</groupId>
                          <artifactId>maven-surefire-plugin</artifactId>
                          <version>2.22.1</version>
                          <configuration>
                          <useSystemClassLoader>false</useSystemClassLoader>
                          </configuration>
                          </plugin>
                          </plugins>
                          </build>
                          [...]
                          </project>






                          share|improve this answer












                          share|improve this answer



                          share|improve this answer










                          answered Nov 3 at 4:51









                          Arunkumar Arjunan

                          881110




                          881110





















                              4














                              The suggestion above to set the property "-Djdk.net.URLClassPath.disableClassPathURLCheck=true" did NOT work for me, but setting the following does work OK:



                              -DforkCount=0





                              share|improve this answer


















                              • 2




                                This has the effect of not creating a new VM for running the tests, so the tests can possibly influence the main build VM.
                                – Paŭlo Ebermann
                                Nov 6 at 10:25















                              4














                              The suggestion above to set the property "-Djdk.net.URLClassPath.disableClassPathURLCheck=true" did NOT work for me, but setting the following does work OK:



                              -DforkCount=0





                              share|improve this answer


















                              • 2




                                This has the effect of not creating a new VM for running the tests, so the tests can possibly influence the main build VM.
                                – Paŭlo Ebermann
                                Nov 6 at 10:25













                              4












                              4








                              4






                              The suggestion above to set the property "-Djdk.net.URLClassPath.disableClassPathURLCheck=true" did NOT work for me, but setting the following does work OK:



                              -DforkCount=0





                              share|improve this answer














                              The suggestion above to set the property "-Djdk.net.URLClassPath.disableClassPathURLCheck=true" did NOT work for me, but setting the following does work OK:



                              -DforkCount=0






                              share|improve this answer














                              share|improve this answer



                              share|improve this answer








                              edited Nov 18 at 21:58









                              Peter Mortensen

                              13.5k1983111




                              13.5k1983111










                              answered Nov 1 at 16:02









                              farid g.

                              514




                              514







                              • 2




                                This has the effect of not creating a new VM for running the tests, so the tests can possibly influence the main build VM.
                                – Paŭlo Ebermann
                                Nov 6 at 10:25












                              • 2




                                This has the effect of not creating a new VM for running the tests, so the tests can possibly influence the main build VM.
                                – Paŭlo Ebermann
                                Nov 6 at 10:25







                              2




                              2




                              This has the effect of not creating a new VM for running the tests, so the tests can possibly influence the main build VM.
                              – Paŭlo Ebermann
                              Nov 6 at 10:25




                              This has the effect of not creating a new VM for running the tests, so the tests can possibly influence the main build VM.
                              – Paŭlo Ebermann
                              Nov 6 at 10:25











                              4














                              For Ubuntu: Install the latest version, it has this bug fixed



                              sudo apt-get update ; sudo apt-get dist-upgrade -y


                              Install the last working version (without security patches) without the bug.



                              sudo apt-get install openjdk-8-jdk-headless=8u181-b13-1 openjdk-8-jdk=8u181-b13-1 openjdk-8-jre=8u181-b13-1 openjdk-8-jre-headless=8u181-b13-1 openjdk-8-source=8u181-b13-1


                              If you missed that version, use the version before that:



                              sudo apt-get install openjdk-8-jdk-headless=8u162-b12-1 openjdk-8-jdk=8u162-b12-1 openjdk-8-jre=8u162-b12-1 openjdk-8-jre-headless=8u162-b12-1 openjdk-8-source=8u162-b12-1


                              Then use either pinning or watch out that you won't install the broken version.



                              Using -Djdk.net.URLClassPath.disableClassPathURLCheck=true didn't work for me wherever I had put that configuration. Somewhere in my integration-tests it always exited without the old Java version.



                              As mentioned by Erich it's a bug in the Debian package being too strict 911925 and the Surefire-plugin not acting according to the new rules SUREFIRE-1588.






                              share|improve this answer






















                              • Why would anyone suggest to install a version without security patches?! Though other suggestions include skipping tests, huh.
                                – berezovskyi
                                Nov 28 at 15:43






                              • 1




                                You don't need to anymore :-) It's fixed. But for the meantime I had many java projects which I had to work on and my java runtime was nowhere exposed to any new code from outside. So there was a oversee-able risk that was Ok for me. It's everyone's own decision after all :-)
                                – flob
                                Nov 28 at 15:58










                              • Actually you are right, I found that JDK devs walked back on that prop set by default: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8; but major version upgrade to surefire does not seem like the best fix to me, actually.
                                – berezovskyi
                                Nov 28 at 15:59







                              • 1




                                Absolutely! But the changes they had to make are throughout the whole codebase and very invasive. So a minor version change for this fix wouldn't be an option in surefire.
                                – flob
                                Nov 28 at 16:04






                              • 1




                                And unfortunately, 2.x is discontinued and we'll have to make a switch sooner than later: issues.apache.org/jira/browse/…
                                – berezovskyi
                                Nov 28 at 16:05















                              4














                              For Ubuntu: Install the latest version, it has this bug fixed



                              sudo apt-get update ; sudo apt-get dist-upgrade -y


                              Install the last working version (without security patches) without the bug.



                              sudo apt-get install openjdk-8-jdk-headless=8u181-b13-1 openjdk-8-jdk=8u181-b13-1 openjdk-8-jre=8u181-b13-1 openjdk-8-jre-headless=8u181-b13-1 openjdk-8-source=8u181-b13-1


                              If you missed that version, use the version before that:



                              sudo apt-get install openjdk-8-jdk-headless=8u162-b12-1 openjdk-8-jdk=8u162-b12-1 openjdk-8-jre=8u162-b12-1 openjdk-8-jre-headless=8u162-b12-1 openjdk-8-source=8u162-b12-1


                              Then use either pinning or watch out that you won't install the broken version.



                              Using -Djdk.net.URLClassPath.disableClassPathURLCheck=true didn't work for me wherever I had put that configuration. Somewhere in my integration-tests it always exited without the old Java version.



                              As mentioned by Erich it's a bug in the Debian package being too strict 911925 and the Surefire-plugin not acting according to the new rules SUREFIRE-1588.






                              share|improve this answer






















                              • Why would anyone suggest to install a version without security patches?! Though other suggestions include skipping tests, huh.
                                – berezovskyi
                                Nov 28 at 15:43






                              • 1




                                You don't need to anymore :-) It's fixed. But for the meantime I had many java projects which I had to work on and my java runtime was nowhere exposed to any new code from outside. So there was a oversee-able risk that was Ok for me. It's everyone's own decision after all :-)
                                – flob
                                Nov 28 at 15:58










                              • Actually you are right, I found that JDK devs walked back on that prop set by default: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8; but major version upgrade to surefire does not seem like the best fix to me, actually.
                                – berezovskyi
                                Nov 28 at 15:59







                              • 1




                                Absolutely! But the changes they had to make are throughout the whole codebase and very invasive. So a minor version change for this fix wouldn't be an option in surefire.
                                – flob
                                Nov 28 at 16:04






                              • 1




                                And unfortunately, 2.x is discontinued and we'll have to make a switch sooner than later: issues.apache.org/jira/browse/…
                                – berezovskyi
                                Nov 28 at 16:05













                              4












                              4








                              4






                              For Ubuntu: Install the latest version, it has this bug fixed



                              sudo apt-get update ; sudo apt-get dist-upgrade -y


                              Install the last working version (without security patches) without the bug.



                              sudo apt-get install openjdk-8-jdk-headless=8u181-b13-1 openjdk-8-jdk=8u181-b13-1 openjdk-8-jre=8u181-b13-1 openjdk-8-jre-headless=8u181-b13-1 openjdk-8-source=8u181-b13-1


                              If you missed that version, use the version before that:



                              sudo apt-get install openjdk-8-jdk-headless=8u162-b12-1 openjdk-8-jdk=8u162-b12-1 openjdk-8-jre=8u162-b12-1 openjdk-8-jre-headless=8u162-b12-1 openjdk-8-source=8u162-b12-1


                              Then use either pinning or watch out that you won't install the broken version.



                              Using -Djdk.net.URLClassPath.disableClassPathURLCheck=true didn't work for me wherever I had put that configuration. Somewhere in my integration-tests it always exited without the old Java version.



                              As mentioned by Erich it's a bug in the Debian package being too strict 911925 and the Surefire-plugin not acting according to the new rules SUREFIRE-1588.






                              share|improve this answer














                              For Ubuntu: Install the latest version, it has this bug fixed



                              sudo apt-get update ; sudo apt-get dist-upgrade -y


                              Install the last working version (without security patches) without the bug.



                              sudo apt-get install openjdk-8-jdk-headless=8u181-b13-1 openjdk-8-jdk=8u181-b13-1 openjdk-8-jre=8u181-b13-1 openjdk-8-jre-headless=8u181-b13-1 openjdk-8-source=8u181-b13-1


                              If you missed that version, use the version before that:



                              sudo apt-get install openjdk-8-jdk-headless=8u162-b12-1 openjdk-8-jdk=8u162-b12-1 openjdk-8-jre=8u162-b12-1 openjdk-8-jre-headless=8u162-b12-1 openjdk-8-source=8u162-b12-1


                              Then use either pinning or watch out that you won't install the broken version.



                              Using -Djdk.net.URLClassPath.disableClassPathURLCheck=true didn't work for me wherever I had put that configuration. Somewhere in my integration-tests it always exited without the old Java version.



                              As mentioned by Erich it's a bug in the Debian package being too strict 911925 and the Surefire-plugin not acting according to the new rules SUREFIRE-1588.







                              share|improve this answer














                              share|improve this answer



                              share|improve this answer








                              edited Nov 28 at 15:55

























                              answered Nov 5 at 14:15









                              flob

                              2,49312241




                              2,49312241











                              • Why would anyone suggest to install a version without security patches?! Though other suggestions include skipping tests, huh.
                                – berezovskyi
                                Nov 28 at 15:43






                              • 1




                                You don't need to anymore :-) It's fixed. But for the meantime I had many java projects which I had to work on and my java runtime was nowhere exposed to any new code from outside. So there was a oversee-able risk that was Ok for me. It's everyone's own decision after all :-)
                                – flob
                                Nov 28 at 15:58










                              • Actually you are right, I found that JDK devs walked back on that prop set by default: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8; but major version upgrade to surefire does not seem like the best fix to me, actually.
                                – berezovskyi
                                Nov 28 at 15:59







                              • 1




                                Absolutely! But the changes they had to make are throughout the whole codebase and very invasive. So a minor version change for this fix wouldn't be an option in surefire.
                                – flob
                                Nov 28 at 16:04






                              • 1




                                And unfortunately, 2.x is discontinued and we'll have to make a switch sooner than later: issues.apache.org/jira/browse/…
                                – berezovskyi
                                Nov 28 at 16:05
















                              • Why would anyone suggest to install a version without security patches?! Though other suggestions include skipping tests, huh.
                                – berezovskyi
                                Nov 28 at 15:43






                              • 1




                                You don't need to anymore :-) It's fixed. But for the meantime I had many java projects which I had to work on and my java runtime was nowhere exposed to any new code from outside. So there was a oversee-able risk that was Ok for me. It's everyone's own decision after all :-)
                                – flob
                                Nov 28 at 15:58










                              • Actually you are right, I found that JDK devs walked back on that prop set by default: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8; but major version upgrade to surefire does not seem like the best fix to me, actually.
                                – berezovskyi
                                Nov 28 at 15:59







                              • 1




                                Absolutely! But the changes they had to make are throughout the whole codebase and very invasive. So a minor version change for this fix wouldn't be an option in surefire.
                                – flob
                                Nov 28 at 16:04






                              • 1




                                And unfortunately, 2.x is discontinued and we'll have to make a switch sooner than later: issues.apache.org/jira/browse/…
                                – berezovskyi
                                Nov 28 at 16:05















                              Why would anyone suggest to install a version without security patches?! Though other suggestions include skipping tests, huh.
                              – berezovskyi
                              Nov 28 at 15:43




                              Why would anyone suggest to install a version without security patches?! Though other suggestions include skipping tests, huh.
                              – berezovskyi
                              Nov 28 at 15:43




                              1




                              1




                              You don't need to anymore :-) It's fixed. But for the meantime I had many java projects which I had to work on and my java runtime was nowhere exposed to any new code from outside. So there was a oversee-able risk that was Ok for me. It's everyone's own decision after all :-)
                              – flob
                              Nov 28 at 15:58




                              You don't need to anymore :-) It's fixed. But for the meantime I had many java projects which I had to work on and my java runtime was nowhere exposed to any new code from outside. So there was a oversee-able risk that was Ok for me. It's everyone's own decision after all :-)
                              – flob
                              Nov 28 at 15:58












                              Actually you are right, I found that JDK devs walked back on that prop set by default: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8; but major version upgrade to surefire does not seem like the best fix to me, actually.
                              – berezovskyi
                              Nov 28 at 15:59





                              Actually you are right, I found that JDK devs walked back on that prop set by default: hg.openjdk.java.net/jdk/jdk/rev/f54dcfc5a5f8; but major version upgrade to surefire does not seem like the best fix to me, actually.
                              – berezovskyi
                              Nov 28 at 15:59





                              1




                              1




                              Absolutely! But the changes they had to make are throughout the whole codebase and very invasive. So a minor version change for this fix wouldn't be an option in surefire.
                              – flob
                              Nov 28 at 16:04




                              Absolutely! But the changes they had to make are throughout the whole codebase and very invasive. So a minor version change for this fix wouldn't be an option in surefire.
                              – flob
                              Nov 28 at 16:04




                              1




                              1




                              And unfortunately, 2.x is discontinued and we'll have to make a switch sooner than later: issues.apache.org/jira/browse/…
                              – berezovskyi
                              Nov 28 at 16:05




                              And unfortunately, 2.x is discontinued and we'll have to make a switch sooner than later: issues.apache.org/jira/browse/…
                              – berezovskyi
                              Nov 28 at 16:05











                              3














                              For those searching for an answer related to Docker Maven: 3.5.x-jdk-8 on GitLab CI, see this GitHub issue.



                              It appears a 3.5.4-jdk-8 image resulted in upgrade to a minor Java version which somehow affects Surefire's forking mechanism.



                              Rolling back to 3.5.3-jdk-8 image fixed this for me on my GitLab CI server building Java 1.8 code with Surefire 2.20.1.






                              share|improve this answer



























                                3














                                For those searching for an answer related to Docker Maven: 3.5.x-jdk-8 on GitLab CI, see this GitHub issue.



                                It appears a 3.5.4-jdk-8 image resulted in upgrade to a minor Java version which somehow affects Surefire's forking mechanism.



                                Rolling back to 3.5.3-jdk-8 image fixed this for me on my GitLab CI server building Java 1.8 code with Surefire 2.20.1.






                                share|improve this answer

























                                  3












                                  3








                                  3






                                  For those searching for an answer related to Docker Maven: 3.5.x-jdk-8 on GitLab CI, see this GitHub issue.



                                  It appears a 3.5.4-jdk-8 image resulted in upgrade to a minor Java version which somehow affects Surefire's forking mechanism.



                                  Rolling back to 3.5.3-jdk-8 image fixed this for me on my GitLab CI server building Java 1.8 code with Surefire 2.20.1.






                                  share|improve this answer














                                  For those searching for an answer related to Docker Maven: 3.5.x-jdk-8 on GitLab CI, see this GitHub issue.



                                  It appears a 3.5.4-jdk-8 image resulted in upgrade to a minor Java version which somehow affects Surefire's forking mechanism.



                                  Rolling back to 3.5.3-jdk-8 image fixed this for me on my GitLab CI server building Java 1.8 code with Surefire 2.20.1.







                                  share|improve this answer














                                  share|improve this answer



                                  share|improve this answer








                                  edited Nov 18 at 21:55









                                  Peter Mortensen

                                  13.5k1983111




                                  13.5k1983111










                                  answered Oct 30 at 23:33









                                  Simon Diemert

                                  858




                                  858





















                                      1














                                      I recently setup maven job on Jenkins and got stuck into the same problem. I took the suggestion to modify the JAVA env variable and confirm the issue resolved. This is how I tested.



                                      Becomes "jenkins" user and change folder to workspace project name that you setup for the job.



                                       $ _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true mvn clean install -U

                                      $ lsb_release -rd
                                      Description: Ubuntu 16.04.5 LTS
                                      Release: 16.04

                                      $ mvn -v
                                      Apache Maven 3.3.9
                                      Maven home: /usr/share/maven
                                      Java version: 1.8.0_181, vendor: Oracle Corporation
                                      Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
                                      Default locale: en_US, platform encoding: UTF-8
                                      OS name: "linux", version: "4.4.0-131-generic", arch: "amd64", family: "unix"





                                      share|improve this answer



























                                        1














                                        I recently setup maven job on Jenkins and got stuck into the same problem. I took the suggestion to modify the JAVA env variable and confirm the issue resolved. This is how I tested.



                                        Becomes "jenkins" user and change folder to workspace project name that you setup for the job.



                                         $ _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true mvn clean install -U

                                        $ lsb_release -rd
                                        Description: Ubuntu 16.04.5 LTS
                                        Release: 16.04

                                        $ mvn -v
                                        Apache Maven 3.3.9
                                        Maven home: /usr/share/maven
                                        Java version: 1.8.0_181, vendor: Oracle Corporation
                                        Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
                                        Default locale: en_US, platform encoding: UTF-8
                                        OS name: "linux", version: "4.4.0-131-generic", arch: "amd64", family: "unix"





                                        share|improve this answer

























                                          1












                                          1








                                          1






                                          I recently setup maven job on Jenkins and got stuck into the same problem. I took the suggestion to modify the JAVA env variable and confirm the issue resolved. This is how I tested.



                                          Becomes "jenkins" user and change folder to workspace project name that you setup for the job.



                                           $ _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true mvn clean install -U

                                          $ lsb_release -rd
                                          Description: Ubuntu 16.04.5 LTS
                                          Release: 16.04

                                          $ mvn -v
                                          Apache Maven 3.3.9
                                          Maven home: /usr/share/maven
                                          Java version: 1.8.0_181, vendor: Oracle Corporation
                                          Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
                                          Default locale: en_US, platform encoding: UTF-8
                                          OS name: "linux", version: "4.4.0-131-generic", arch: "amd64", family: "unix"





                                          share|improve this answer














                                          I recently setup maven job on Jenkins and got stuck into the same problem. I took the suggestion to modify the JAVA env variable and confirm the issue resolved. This is how I tested.



                                          Becomes "jenkins" user and change folder to workspace project name that you setup for the job.



                                           $ _JAVA_OPTIONS=-Djdk.net.URLClassPath.disableClassPathURLCheck=true mvn clean install -U

                                          $ lsb_release -rd
                                          Description: Ubuntu 16.04.5 LTS
                                          Release: 16.04

                                          $ mvn -v
                                          Apache Maven 3.3.9
                                          Maven home: /usr/share/maven
                                          Java version: 1.8.0_181, vendor: Oracle Corporation
                                          Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
                                          Default locale: en_US, platform encoding: UTF-8
                                          OS name: "linux", version: "4.4.0-131-generic", arch: "amd64", family: "unix"






                                          share|improve this answer














                                          share|improve this answer



                                          share|improve this answer








                                          edited Nov 22 at 19:40

























                                          answered Nov 22 at 19:32









                                          Boonchu Ngampairoijpibul

                                          112




                                          112





















                                              0














                                              I uninstalled the JDK that comes in the repositories:



                                              $ sudo apt purge openjdk-8-jdk

                                              $ sudo apt autoremove


                                              Then I deleted the JAVA_HOME environment variable. Mine was set in my .bashrc.



                                              Then I reinstalled it through SDKMAN:



                                              $ sdk install java 8.0.181-zulu


                                              From their site:




                                              SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems. It provides a convenient Command Line Interface (CLI) and API for installing, switching, removing and listing Candidates.




                                              To see other versions of the JDK to install, use:



                                              $ sdk list java





                                              share|improve this answer



























                                                0














                                                I uninstalled the JDK that comes in the repositories:



                                                $ sudo apt purge openjdk-8-jdk

                                                $ sudo apt autoremove


                                                Then I deleted the JAVA_HOME environment variable. Mine was set in my .bashrc.



                                                Then I reinstalled it through SDKMAN:



                                                $ sdk install java 8.0.181-zulu


                                                From their site:




                                                SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems. It provides a convenient Command Line Interface (CLI) and API for installing, switching, removing and listing Candidates.




                                                To see other versions of the JDK to install, use:



                                                $ sdk list java





                                                share|improve this answer

























                                                  0












                                                  0








                                                  0






                                                  I uninstalled the JDK that comes in the repositories:



                                                  $ sudo apt purge openjdk-8-jdk

                                                  $ sudo apt autoremove


                                                  Then I deleted the JAVA_HOME environment variable. Mine was set in my .bashrc.



                                                  Then I reinstalled it through SDKMAN:



                                                  $ sdk install java 8.0.181-zulu


                                                  From their site:




                                                  SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems. It provides a convenient Command Line Interface (CLI) and API for installing, switching, removing and listing Candidates.




                                                  To see other versions of the JDK to install, use:



                                                  $ sdk list java





                                                  share|improve this answer














                                                  I uninstalled the JDK that comes in the repositories:



                                                  $ sudo apt purge openjdk-8-jdk

                                                  $ sudo apt autoremove


                                                  Then I deleted the JAVA_HOME environment variable. Mine was set in my .bashrc.



                                                  Then I reinstalled it through SDKMAN:



                                                  $ sdk install java 8.0.181-zulu


                                                  From their site:




                                                  SDKMAN! is a tool for managing parallel versions of multiple Software Development Kits on most Unix based systems. It provides a convenient Command Line Interface (CLI) and API for installing, switching, removing and listing Candidates.




                                                  To see other versions of the JDK to install, use:



                                                  $ sdk list java






                                                  share|improve this answer














                                                  share|improve this answer



                                                  share|improve this answer








                                                  edited Nov 18 at 22:03









                                                  Peter Mortensen

                                                  13.5k1983111




                                                  13.5k1983111










                                                  answered Nov 16 at 18:55









                                                  jumpnett

                                                  4,63711322




                                                  4,63711322





















                                                      0














                                                      I was facing the same issue with gitlab ci, changing maven image from maven:3-jdk-8 to maven:3.6.0-jdk-8-alpine seems to fix the issue. Btw I also tested with maven:3.6.0-jdk-8 but it didn't work neither.






                                                      share|improve this answer

























                                                        0














                                                        I was facing the same issue with gitlab ci, changing maven image from maven:3-jdk-8 to maven:3.6.0-jdk-8-alpine seems to fix the issue. Btw I also tested with maven:3.6.0-jdk-8 but it didn't work neither.






                                                        share|improve this answer























                                                          0












                                                          0








                                                          0






                                                          I was facing the same issue with gitlab ci, changing maven image from maven:3-jdk-8 to maven:3.6.0-jdk-8-alpine seems to fix the issue. Btw I also tested with maven:3.6.0-jdk-8 but it didn't work neither.






                                                          share|improve this answer












                                                          I was facing the same issue with gitlab ci, changing maven image from maven:3-jdk-8 to maven:3.6.0-jdk-8-alpine seems to fix the issue. Btw I also tested with maven:3.6.0-jdk-8 but it didn't work neither.







                                                          share|improve this answer












                                                          share|improve this answer



                                                          share|improve this answer










                                                          answered Dec 20 at 13:18









                                                          mndeveci

                                                          142311




                                                          142311





















                                                              -1














                                                              I am used as this as workaround to stop the compilation and execution of test files:



                                                              -Dmaven.test.skip=true with maven





                                                              share|improve this answer


















                                                              • 3




                                                                why would one want to skip the tests?
                                                                – Syed Mauze Rehan
                                                                Nov 21 at 10:42










                                                              • It’s like you’re answering a different question?
                                                                – Ole V.V.
                                                                Dec 18 at 18:31















                                                              -1














                                                              I am used as this as workaround to stop the compilation and execution of test files:



                                                              -Dmaven.test.skip=true with maven





                                                              share|improve this answer


















                                                              • 3




                                                                why would one want to skip the tests?
                                                                – Syed Mauze Rehan
                                                                Nov 21 at 10:42










                                                              • It’s like you’re answering a different question?
                                                                – Ole V.V.
                                                                Dec 18 at 18:31













                                                              -1












                                                              -1








                                                              -1






                                                              I am used as this as workaround to stop the compilation and execution of test files:



                                                              -Dmaven.test.skip=true with maven





                                                              share|improve this answer














                                                              I am used as this as workaround to stop the compilation and execution of test files:



                                                              -Dmaven.test.skip=true with maven






                                                              share|improve this answer














                                                              share|improve this answer



                                                              share|improve this answer








                                                              edited Nov 18 at 22:02









                                                              Peter Mortensen

                                                              13.5k1983111




                                                              13.5k1983111










                                                              answered Nov 8 at 13:43









                                                              sarir

                                                              513




                                                              513







                                                              • 3




                                                                why would one want to skip the tests?
                                                                – Syed Mauze Rehan
                                                                Nov 21 at 10:42










                                                              • It’s like you’re answering a different question?
                                                                – Ole V.V.
                                                                Dec 18 at 18:31












                                                              • 3




                                                                why would one want to skip the tests?
                                                                – Syed Mauze Rehan
                                                                Nov 21 at 10:42










                                                              • It’s like you’re answering a different question?
                                                                – Ole V.V.
                                                                Dec 18 at 18:31







                                                              3




                                                              3




                                                              why would one want to skip the tests?
                                                              – Syed Mauze Rehan
                                                              Nov 21 at 10:42




                                                              why would one want to skip the tests?
                                                              – Syed Mauze Rehan
                                                              Nov 21 at 10:42












                                                              It’s like you’re answering a different question?
                                                              – Ole V.V.
                                                              Dec 18 at 18:31




                                                              It’s like you’re answering a different question?
                                                              – Ole V.V.
                                                              Dec 18 at 18:31











                                                              -2














                                                              If like me you have issues in your pipeline (for me it's in GitLab, but whatever) and if you are using a Maven JDK 8 Docker image.



                                                              You can replace



                                                              image: maven:3.5.4-jdk-8


                                                              by the last working build



                                                              image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b





                                                              share|improve this answer


















                                                              • 1




                                                                The problem comes from the latest jdk8 for debian, In my opinion it's better to "fix" the core problem than to try to work around it.
                                                                – Sylordis
                                                                Oct 31 at 16:32










                                                              • The sha256 sound tricky and afraid you ? Actually other answer looks more like a work around, disable some feature from surefire, here it's just about use the last working docker image without changing your working pom or pipeline which is a work around.
                                                                – amdev
                                                                Nov 2 at 8:21















                                                              -2














                                                              If like me you have issues in your pipeline (for me it's in GitLab, but whatever) and if you are using a Maven JDK 8 Docker image.



                                                              You can replace



                                                              image: maven:3.5.4-jdk-8


                                                              by the last working build



                                                              image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b





                                                              share|improve this answer


















                                                              • 1




                                                                The problem comes from the latest jdk8 for debian, In my opinion it's better to "fix" the core problem than to try to work around it.
                                                                – Sylordis
                                                                Oct 31 at 16:32










                                                              • The sha256 sound tricky and afraid you ? Actually other answer looks more like a work around, disable some feature from surefire, here it's just about use the last working docker image without changing your working pom or pipeline which is a work around.
                                                                – amdev
                                                                Nov 2 at 8:21













                                                              -2












                                                              -2








                                                              -2






                                                              If like me you have issues in your pipeline (for me it's in GitLab, but whatever) and if you are using a Maven JDK 8 Docker image.



                                                              You can replace



                                                              image: maven:3.5.4-jdk-8


                                                              by the last working build



                                                              image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b





                                                              share|improve this answer














                                                              If like me you have issues in your pipeline (for me it's in GitLab, but whatever) and if you are using a Maven JDK 8 Docker image.



                                                              You can replace



                                                              image: maven:3.5.4-jdk-8


                                                              by the last working build



                                                              image: maven@sha256:b37da91062d450f3c11c619187f0207bbb497fc89d265a46bbc6dc5f17c02a2b






                                                              share|improve this answer














                                                              share|improve this answer



                                                              share|improve this answer








                                                              edited Nov 18 at 21:56









                                                              Peter Mortensen

                                                              13.5k1983111




                                                              13.5k1983111










                                                              answered Oct 31 at 8:42









                                                              amdev

                                                              1,1421535




                                                              1,1421535







                                                              • 1




                                                                The problem comes from the latest jdk8 for debian, In my opinion it's better to "fix" the core problem than to try to work around it.
                                                                – Sylordis
                                                                Oct 31 at 16:32










                                                              • The sha256 sound tricky and afraid you ? Actually other answer looks more like a work around, disable some feature from surefire, here it's just about use the last working docker image without changing your working pom or pipeline which is a work around.
                                                                – amdev
                                                                Nov 2 at 8:21












                                                              • 1




                                                                The problem comes from the latest jdk8 for debian, In my opinion it's better to "fix" the core problem than to try to work around it.
                                                                – Sylordis
                                                                Oct 31 at 16:32










                                                              • The sha256 sound tricky and afraid you ? Actually other answer looks more like a work around, disable some feature from surefire, here it's just about use the last working docker image without changing your working pom or pipeline which is a work around.
                                                                – amdev
                                                                Nov 2 at 8:21







                                                              1




                                                              1




                                                              The problem comes from the latest jdk8 for debian, In my opinion it's better to "fix" the core problem than to try to work around it.
                                                              – Sylordis
                                                              Oct 31 at 16:32




                                                              The problem comes from the latest jdk8 for debian, In my opinion it's better to "fix" the core problem than to try to work around it.
                                                              – Sylordis
                                                              Oct 31 at 16:32












                                                              The sha256 sound tricky and afraid you ? Actually other answer looks more like a work around, disable some feature from surefire, here it's just about use the last working docker image without changing your working pom or pipeline which is a work around.
                                                              – amdev
                                                              Nov 2 at 8:21




                                                              The sha256 sound tricky and afraid you ? Actually other answer looks more like a work around, disable some feature from surefire, here it's just about use the last working docker image without changing your working pom or pipeline which is a work around.
                                                              – amdev
                                                              Nov 2 at 8:21

















                                                              draft saved

                                                              draft discarded
















































                                                              Thanks for contributing an answer to Stack Overflow!


                                                              • Please be sure to answer the question. Provide details and share your research!

                                                              But avoid


                                                              • Asking for help, clarification, or responding to other answers.

                                                              • Making statements based on opinion; back them up with references or personal experience.

                                                              To learn more, see our tips on writing great answers.





                                                              Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                                                              Please pay close attention to the following guidance:


                                                              • Please be sure to answer the question. Provide details and share your research!

                                                              But avoid


                                                              • Asking for help, clarification, or responding to other answers.

                                                              • Making statements based on opinion; back them up with references or personal experience.

                                                              To learn more, see our tips on writing great answers.




                                                              draft saved


                                                              draft discarded














                                                              StackExchange.ready(
                                                              function ()
                                                              StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53010200%2fmaven-surefire-could-not-find-forkedbooter-class%23new-answer', 'question_page');

                                                              );

                                                              Post as a guest















                                                              Required, but never shown





















































                                                              Required, but never shown














                                                              Required, but never shown












                                                              Required, but never shown







                                                              Required, but never shown

































                                                              Required, but never shown














                                                              Required, but never shown












                                                              Required, but never shown







                                                              Required, but never shown







                                                              這個網誌中的熱門文章

                                                              What does pagestruct do in Eviews?

                                                              Dutch intervention in Lombok and Karangasem

                                                              Channel Islands