Reputation: 4047
Please help me to solve this issue. I do not exactly understand what the error in the log means.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 21.749s
[INFO] Finished at: Thu Apr 24 10:10:20 IST 2014
[INFO] Final Memory: 15M/37M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test (default-test) on project samples.simpleforwarding: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.15:test failed: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ?
[ERROR] Command wascmd.exe /X /C ""C:\Program Files\Java\jdk1.7.0_55\jre\bin\java" -Xmx1024m -XX:MaxPermSize=256m -jar E:\OpenDayLight\controller\opendaylight\samples\simpleforwarding\target\surefire\surefirebooter53410321571238933.jar E:\OpenDayLight\controller\opendaylight\samples\simpleforwarding\target\surefire\surefire86076271125218001tmp E:\OpenDayLight\controller\opendaylight\samples\simpleforwarding\target\surefire\surefire_01846991116135903536tmp"
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
Upvotes: 334
Views: 426077
Reputation: 4818
I had the same problem with Java 8 and spring boot 5.2.7 (plugin is included, out of the box). The version of the plugin is default (2.22.2). In my case the problems were happening only on some machines in team, while on the other machines everything was fine. I guess it have something to do with the number of cores maven detected.
I fixed it with these settings:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<reuseForks>false</reuseForks>
</configuration>
</plugin>
I have tried many of the proposed approaches, but nothing was working in my case.
The only downside with this solution is disabling forks' reuse is causing the tests to run slower now.
Upvotes: 7
Reputation: 65
If you’re using IntelliJ IDEA, you can resolve this issue by adding the following parameters to your Maven test lifecycle configuration:
MAVEN_OPTS=-Xms512m -Xmx1024m -XX:MaxPermSize=1024m
Steps to Apply:
Open your Maven tool window in IntelliJ IDEA.
Right-click on the test lifecycle phase and select Edit Configuration.
In the dialog that appears: • Under Java Options, uncheck the “Inherit from settings” box if needed. • Add the environment variable MAVEN_OPTS with the value: -Xms512m -Xmx1024m -XX:MaxPermSize=1024m 4. Click Apply and OK.
Here are the relevant screenshots for reference:
Upvotes: 0
Reputation: 19285
My scenario is
mvn
command is executed from a command line..dump
file from Surefire plugin or traditional hs_err
crash files from Java binary.Two things consistently worked as solutions for me (they are alternatives):
forkCount = 0
. See below under "forkCount solution".forkedProcessExitTimeoutInSeconds
from 30 secs to say 300 secs. The plugin documentation says that if this timeout is hit you'll see error message There was a timeout in the fork
. I saw no such error message, yet it consistently fixes the problem to increase this timeout value. See below under "forkedProcessExitTimeoutInSeconds solution".You would probably want to use solution (2) as forking is desirable.
My theory is that if lots of log output then there's still lots of processing that needs to be done on fork shutdown (in particular if you are running inside an IDE which captures the output and possibly uses a memory mapped files for its window content). In short: at the time the test is finished there's still a lot of text waiting to be forwarded into your IDE. It seems 30s simply isn't enough for this.
This also explains why some devs will see the problem, while others not. How much output processing is left to do at the time of test finish is probably a function of cpu power, disk speed, etc.
If I'm right in this - cannot prove it - then all suggestions like redirecting the log output and decreasing the logging level are IMO treating the symptom, not the cause.
forkCount solution:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkCount>0</forkCount>
</configuration>
</plugin>
forkedProcessExitTimeoutInSeconds solution:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkedProcessExitTimeoutInSeconds>300</forkedProcessExitTimeoutInSeconds>
</configuration>
</plugin>
Upvotes: 33
Reputation: 1206
Found a new solution for 2024. My Project is Spring-Boot 3.x, Java 17:
Error Log:
...
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:3.2.5:test (default-test) on project rest-clients:
[ERROR]
[ERROR] Please refer to /rest-clients/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] ExecutionException Error occurred in starting fork, check output in log
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: ExecutionException Error occurred in starting fork, check output in log
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.awaitResultsDone(ForkStarter.java:456)
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkOnceMultiple(ForkStarter.java:358)
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:296)
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:250)
[ERROR] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1241)
[ERROR] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1090)
[ERROR] at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:910)
[ERROR] at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:370)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:351)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:215)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:171)
[ERROR] at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:163)
[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:294)
[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:960)
[ERROR] at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:293)
[ERROR] at org.apache.maven.cli.MavenCli.main(MavenCli.java:196)
[ERROR] at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
[ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:580)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:282)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:225)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:406)
[ERROR] at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:347)
[ERROR] at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
[ERROR] at java.base/java.lang.reflect.Method.invoke(Method.java:580)
[ERROR] at org.apache.maven.wrapper.BootstrapMainStarter.start(BootstrapMainStarter.java:52)
[ERROR] at org.apache.maven.wrapper.WrapperExecutor.execute(WrapperExecutor.java:161)
[ERROR] at org.apache.maven.wrapper.MavenWrapperMain.main(MavenWrapperMain.java:73)
[ERROR] Caused by: org.apache.maven.surefire.booter.SurefireBooterForkException: Error occurred in starting fork, check output in log
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:577)
[ERROR] at org.apache.maven.plugin.surefire.booterclient.ForkStarter.lambda$null$3(ForkStarter.java:350)
[ERROR] at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
[ERROR] at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
[ERROR] at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
[ERROR] at java.base/java.lang.Thread.run(Thread.java:1583)
[ERROR]
[ERROR] -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
I had a Spring-Boot Test that took a long time to shut down gracefully. My Tests are written using the Spock Framework.
The config which worked for me was surefire config property shutdown. When you use value testset
, the docs say: "With(shutdown=testset) the test set may still continue to run in forked JVM."
My understanding this changes the default 'force kill' forks behavior to a synchronous 'wait for test set to exit on it's own' behavior.
So I used this property to remove the error, so far successfully when running the maven commands from within IntelliJ IDEA, MacOS Terminal (ZSH), or Jenkins SH step.
I'm using the following plugin version properties & plugin configs in my pom.xml to execute Spring-Boot Tests written with the Spock Framework and the jacoco-maven-plugin to generate a test coverage report.
<properties>
<maven-surefire-plugin.version>3.2.5</maven-surefire-plugin.version><!-- Check the latest version: https://mvnrepository.com/artifact/org.apache.maven.plugins/maven-surefire-plugin -->
<gmavenplus-plugin.version>3.0.2</gmavenplus-plugin.version><!-- Check the latest version: https://mvnrepository.com/artifact/org.codehaus.gmavenplus/gmavenplus-plugin -->
<jacoco-maven-plugin.version>0.8.11</jacoco-maven-plugin.version><!-- Check the latest version: https://mvnrepository.com/artifact/org.jacoco/jacoco-maven-plugin -->
</properties>
<build>
<plugins>
<!-- Test Plugins :: Start -->
<plugin>
<groupId>org.codehaus.gmavenplus</groupId>
<artifactId>gmavenplus-plugin</artifactId>
<version>${gmavenplus-plugin.version}</version>
<executions>
<execution>
<goals>
<goal>addTestSources</goal>
<goal>compileTests</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
<configuration>
<parallel>classes</parallel>
<threadCount>4</threadCount>
<forkCount>2</forkCount>
<!-- jacoco-maven-plugin :: When using the maven-surefire-plugin or maven-failsafe-plugin you must not use
a `forkCount` of `0` or set the `forkMode` to `never` as this would prevent the execution of the tests
with the javaagent set and no coverage would be recorded.
@see https://www.jacoco.org/jacoco/trunk/doc/maven.html
-->
<!-- After the plugin process is shutdown by sending SIGTERM signal (CTRL+C), SHUTDOWN command is received by
every forked JVM. The value is set to (shutdown=exit) by default (changed in version 3.0.0-M4). The
parameter can be configured with other two values testset and kill. With(shutdown=testset) the test set
may still continue to run in forked JVM. Using exit forked JVM executes System.exit(1) after the plugin
process has received SIGTERM signal.
Maven Docs: https://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html
StackOverflow:
-->
<shutdown>testset</shutdown>
<!--suppress UnresolvedMavenProperty -->
<argLine>${maven-surefire-plugin.jvm-flags} ${argLine}</argLine>
<includes>
<include>**/*Spec.java</include>
<include>**/*Test.java</include>
</includes>
</configuration>
</plugin>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>${jacoco-maven-plugin.version}</version>
<executions>
<execution>
<id>jacoco-initialize</id>
<phase>process-test-classes</phase><!-- https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference -->
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>jacoco-report</id>
<phase>test</phase><!-- https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference -->
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>jacoco-check</id>
<phase>test</phase><!-- https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference -->
<goals>
<goal>check</goal>
</goals>
<configuration>
<haltOnFailure>false</haltOnFailure><!-- https://www.jacoco.org/jacoco/trunk/doc/check-mojo.html#haltOnFailure -->
<rules>
<rule>
<element>PACKAGE</element>
<limits>
<limit>
<counter>METHOD</counter>
<value>COVEREDRATIO</value>
<minimum>80%</minimum>
</limit>
<limit>
<counter>CLASS</counter>
<value>MISSEDCOUNT</value>
<maximum>0</maximum>
</limit>
</limits>
</rule>
</rules>
</configuration>
</execution>
</executions>
</plugin>
<!-- Test Plugins :: End -->
</plugins>
</build>
Upvotes: 0
Reputation: 1
Your java version is not compatible with this project . Please downgrade you java version from the system and set the path and run the project. i hope it would resolved the issue.
best if luck!!
Upvotes: 0
Reputation: 117
What fixed it for me was to add to both surefire
and failsafe
plugins the following configuration:
<configuration>
<reuseForks>false</reuseForks>
<forkCount>0</forkCount>
</configuration>
Upvotes: 0
Reputation: 2904
In my case, I used javaagent in integration tests. I found that javaagent wasn't downloaded and this led to such error. So ensure your application can access javaagent.
Upvotes: 0
Reputation: 1
I tried updating sure-fire plug-in configurations as well as updating maven settings.xml. It did not work for me. Finally tried exporting the console output to the .txt file and issue got resolved.
Upvotes: 0
Reputation: 3137
If you are running sonar build by clean verify sonar:sonar and some of the file that generating lots of logs, that logs is issuing this vm termination.
To solve this issue you can follow below steps.
In the test resources, add logback-test.xml.
Change the log level to INFO mode.
in maven-surefire-plugin add below configuration.
<configuration>
<reuseForks>false</reuseForks>
<forkCount>1</forkCount>
</configuration>
Now the INFO log will be generated and vm will not crash.
Upvotes: 1
Reputation: 3721
I tried many of the solutions described here. None solved the problem. Eventually, the only thing that helped was an upgrade of maven itself from v3.6.1 to v3.8.6. (I used corretto jdk11.0.12_7 for the build)
Upvotes: 0
Reputation: 101
I forgot to declare maven-surefire in my Java 7 project's pom.xml, so it defaulted to use the Java 8 version in maven's runtime. (i thought it was declared in a parent)
Adding surefire to the build section in the pom solved the problem.
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12</version>
<configuration>
<argLine>-XX:-UseSplitVerifier</argLine>
<skip>${maven.skip}</skip>
<skipTests>${maven.skipTests}</skipTests>
</configuration>
</plugin>
</plugins>
</build>
Upvotes: 0
Reputation: 130
It hapenned to me at some point after dozens of Maven runs in debug mode:
-Dmaven.surefire.debug="-agentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=5005"
I had to kill extra java processes that were still running for some reasons in parallel.
Upvotes: 1
Reputation: 3003
I had the same problem while after updating Maven from 2.6.3 to 2.8.4. The problem was that forked JVM crushed by out of memory, so just increased memory from 1024Mb to 2048Mb in Surefire plugin config and that solved the issue
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<!--suppress UnresolvedMavenProperty -->
<argLine>${argLine} -Dfile.encoding=UTF-8 -Xmx2048m</argLine>
</configuration>
</plugin>
Upvotes: 0
Reputation: 2571
Solution that worked for me, set: <forkCount>0</forkCount>
i.e.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkCount>0</forkCount>
<argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>
</configuration>
</plugin>
Upvotes: 7
Reputation: 1
This worked for me.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M5</version>
<configuration>
<argLine>-Dfile.encoding=UTF-8</argLine>
</configuration>
</plugin>
Upvotes: 0
Reputation: 1
my resolution was to change the timeout mentioned in Jenkinsfile from 90 to 120.
pipeline {
agent { label projectName }
options {
disableConcurrentBuilds()
buildDiscarder(logRotator(numToKeepStr:'5'))
timeout(time: 90, unit: 'MINUTES')
}
Thanks, SA
Upvotes: 0
Reputation: 111
you can use below command. Because your unit tests need to fork. That problem about you use thread in your unit test.
mvn test -DforkCount=2
I hope. Its helpful.
Upvotes: 5
Reputation: 61
Happened to me: if your project depends on docker machine or/ and database to build successfully then please check first that your db instance is up and your docker is also up because maybe there are some unit tests running in the background ... check that especially after starting your laptop.. hope that could help someone
Upvotes: 0
Reputation: 93
I recently had the same problem in an application generated by JHipster 6.10.5 using spring-boot 2.2.7.RELEASE and maven surefire plugin 3.0.0-M4 . It was caused by a timeout due to the extremely long testing log. It was solved by adding the following configuration parameter to maven-surefire-plugin in pom.xml (under pluginManagement):
<forkedProcessExitTimeoutInSeconds>1200</forkedProcessExitTimeoutInSeconds>
Upvotes: 4
Reputation: 91
Simple solution: You should add src/test/resources/logback.xml
<configuration debug="false">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%date{HH:mm:ss.SSS} %highlight(%-5level)
%gray(%logger{90}) %X{X-ApplicationId} %msg%n
</pattern>
</encoder>
</appender>
Upvotes: 3
Reputation: 1068
I had this many time, and for me, this is almost always "console" related and has nothing to do with actual forking.
In short, my solution is :
-B
(batch mode)-Djansi.force=true -Djansi.passthrough=true
On a given project this would fails systematically in a new windows console (cmd.exe)
[path_to_jdk]\java.exe -Dmaven.home=[path_to_maven]\apache-maven-3.6.3 -Dclassworlds.conf=[path_to_maven]\bin..\bin\m2.conf -Dmaven.multiModuleProjectDirectory=[path_to_myproject] -Dfile.encoding=UTF-8 -Djansi.force=true -Djansi.passthrough=true -classpath [path_to_maven]\boot\plexus-classworlds-2.6.0.jar org.codehaus.plexus.classworlds.launcher.Launcher clean install -B
This will always works in a new console window (cmd.exe).
[path_to_jdk]\java.exe -Dmaven.home=[path_to_maven]\apache-maven-3.6.3 -Dclassworlds.conf=[path_to_maven]\bin..\bin\m2.conf -Dmaven.multiModuleProjectDirectory=[path_to_myproject] -Dfile.encoding=UTF-8 -Djansi.force=true -Djansi.passthrough=true -classpath [path_to_maven]\boot\plexus-classworlds-2.6.0.jar org.codehaus.plexus.classworlds.launcher.Launcher clean install -B
Notice that both command have -B (batch mode which should turn off coloring), and the only difference is
-Djansi.force=true -Djansi.passthrough=true
Now I just need to be able to pass these "JVM args" the the "mvn.cmd" to make this better.
Something like this I guess : Is there a way to pass jvm args via command line to maven?
A bit of background :
I had this problem repeatedly since the latest versions of maven (3.x +). I have tried many of the solutions here, sometimes with luck, sometimes not.
This article from the official doc has always been useless : https://maven.apache.org/surefire/maven-surefire-plugin/examples/class-loading.html
But there are constants, when I ran in this problem :
The key discovery was that I noticed that within Eclipse, (with or without the embedded maven version) a ful maven build (clean install) would work.
So I figured out which command Eclipse was using (thanks : How do I get the command-line for an Eclipse run configuration?)
From there, I was able to determine was the solution was.
See other answer where people are saying
There is clearly a bug there. Either in Maven or in the windows console, or in the Jansi lib, or in the integration of these components.
Upvotes: 0
Reputation: 503
Turn off useSystemClassLoader of maven-surefile-plugin should help
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.0</version>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
</configuration>
</plugin>
Upvotes: 16
Reputation: 152
this error I was able to remove after adding profile:
<profile>
<id>surefire-windows-fork-disable</id>
<activation>
<os>
<family>Windows</family>
</os>
</activation>
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<forkCount>0</forkCount>
<useSystemClassLoader>false</useSystemClassLoader>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>
</profile>
seems that this is a windows problem regarding maven surefire forks
Upvotes: 1
Reputation: 28016
I had the same problem in an app that was logging lots of XML to the console whilst it was running tests. I think the issue is something to do with the way the test fork sends its console logging to the main maven thread to be output to the screen.
I worked around the issue by setting the logging of the offending class to WARN in my test logback file.
Eg logback-test.xml
<configuration debug="true">
<include resource="org/springframework/boot/logging/logback/defaults.xml" />
<include resource="org/springframework/boot/logging/logback/console-appender.xml" />
<logger name="com.foo.ClassWithLotsOfXmlLogging" level="WARN" />
<root level="INFO">
<appender-ref ref="CONSOLE"/>
</root>
</configuration>
Upvotes: 0
Reputation: 584
This seems to be a thread sync issue on certain Windows machines. If you're having this problem with Windows, try redirecting the output to a file: mvn clean install > output.txt
Upvotes: 6
Reputation: 12441
I updated the surefire plugin to the following and this solved my problem:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.2</version>
<configuration>
<argLine>-Xmx1024m -XX:MaxPermSize=256m</argLine>
<forkCount>1</forkCount>
<reuseForks>true</reuseForks>
<runOrder>alphabetical</runOrder>
</configuration>
</plugin>
Upvotes: 2
Reputation: 21
I was facing the same issue when running unit tests using maven test . Tried changing the surefire versions but it dinnt work. Finally managed to solve as follows: EARLIER: (when the issue was happening): javac is from jdk 1.8 java was pointing to the java bin from jdk 1.11 CURRENT: (when the issue got resolved): both javac & java are pointing to the bins from jdk 1.8
Regards Teja .
Upvotes: 1
Reputation: 1
I was using folder name As test&demo so it was giving this problem (VM terminated without saying properly goodbye. VM crash or System.exit called),but When i gave folder name as test_demo then it solved this issue.(this problem is there with windows OS with "&" symbol.)
Replace "&" to "_"
This problem may cause with some special symbol or extra space in folder name.
Upvotes: 0
Reputation: 627
version 2.22.2 has real problems with forked JVMs. Use version 2.20 - it works like a charm!
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.20</version>
Upvotes: 9
Reputation: 868
I had a situation similar to Chad's, but found a different answer.
Per the plugin docs, you can't use ${...}
in <argLine>
because Maven will pick that up for replacement before the surefire plugin (or any other plugin) does.
Since version 2.17, the plugin supports @{...}
instead of ${...}
for property replacement.
So for example, replace this
<argLine>XX:MaxPermSize=1024m ${moreArgs}</argLine>
with this
<argLine>XX:MaxPermSize=1024m @{moreArgs}</argLine>
Upvotes: 1