使用SureFire插件的麻烦： – “分叉的虚拟机终止而没有说再见。 VM崩溃或System.exit调用？ “
在发生exception后运行unit testing：
org.apache.maven.lifecycle.LifecycleExecutionException: ExecutionException; nested exception is java.util.concurrent.ExecutionException: java.lang.RuntimeException: The forked VM terminated without saying properly goodbye. VM crash or System.exit called ? at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:600) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) 有什么建议么？
有什么建议么？
exception的错误消息可能解释了发生了什么。 你的一个unit testing也有
- 叫做
System.exit()，或者 - 破坏了unit testing线束，或
- 做了一些已经崩溃了运行它的JVM的东西。
我们不能告诉你它是哪个。
（我想这个问题正在被报告，因为maven JVM期望子JVM将unit testing结果写入其标准输出。它从孩子那里得到的是错过了说unit testing的消息（或其他）已经完成了。根本原因可能与建议的替代方案有所不同，但我对此表示怀疑，并且毫无意义推测……）
日志文件中可能存在更多有关违规unit testing的信息。 检查/他们。
我在运行maven目标“包”时遇到了同样的问题。 在执行“package”之前执行目标“clean”时问题得到了解决
我有同样的问题。 原来我更新了我的lib而没有更新我的java版本，我有一个太新的servlet.jar。 在’forked VM bla exception’之前，我在日志中发现了以下消息：
Caused by: java.lang.UnsupportedClassVersionError: javax/servlet/ServletRequest : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2427) at java.lang.Class.getMethod0(Class.java:2670) at java.lang.Class.getMethod(Class.java:1603) at org.apache.maven.surefire.util.ReflectionUtils.tryGetMethod(ReflectionUtils.java:57) at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isSuiteOnly(JUnit3TestChecker.java:64) at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.isValidJUnit3Test(JUnit3TestChecker.java:59) at org.apache.maven.surefire.common.junit3.JUnit3TestChecker.accept(JUnit3TestChecker.java:54) at org.apache.maven.surefire.common.junit4.JUnit4TestChecker.accept(JUnit4TestChecker.java:51) at org.apache.maven.surefire.util.DefaultScanResult.applyFilter(DefaultScanResult.java:97) at org.apache.maven.surefire.junit4.JUnit4Provider.scanClassPath(JUnit4Provider.java:194) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:92)
更新JVM有帮助。
我在jenkins中遇到同样的问题，如同在接受的答案中报告的那样，并且失去了一个小时才意识到问题是jenkins的工作名称中有一个空格，这是在制造一些东西（仍然不知道是什么） invfire插件的调用变得疯狂，因为作业名称是jenkins工作区内的所有内容的文件夹。
所以，要明确的是，jenkins与这个问题毫无关系，我只是在jenkins看到它，因为只有我在路径上有一个空间
我希望这有助于其他人。 这是肯定的2.14.1和2.16。
这可能与管理员权限有关。 从Cygwin运行build mvn clean install时，我遇到了同样的问题。
现在每次构建我都会启动cygwin作为“以管理员身份运行”，问题就解决了。