请帮我解决这个问题。我不太明白日志中的错误是什么意思。
[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
我遇到过一个案例，其中没有一个答案能解决问题。它是一个遗留应用程序，恰好使用log4j和SLF4J/logback。
前面的情况:干净的测试构建在Eclipse中启动时运行良好，但是在命令行中启动时，出现了这个错误。基于CircleCI的CI构建也运行良好。
我所做的是:出于纯粹的猜测，配置一个适当的logback-test.xml并降低日志记录的冗长程度。你瞧，我再也没有遇到过这个错误，我现在可以从命令行构建项目(以及发生这个错误的模块)。
我的观点是，日志框架的使用或配置方式可能是另一种解释。
log4j和logback之间真的有冲突吗?或者仅仅是测试产生的大量日志以某种方式溢出了命令行缓冲区?我不知道。这对我来说仍然是个谜。
当我遇到这个错误时，这是由于我的ulimit打开文件(ulimit -n)太低。它(不知何故)被设置为仅256:
% ulimit -n
256
在我增加限制后，错误消失了:
% ulimit -n 3072
% ulimit -n
3072
您的系统可能不允许将限制设置得这么高。例如，当我试图使用更大的数字时，就会发生这种情况:
% ulimit -n 3073
ulimit: setrlimit failed: invalid argument
或者这可能低于您现有的限制，您可能面临不同的根本原因。
我的设想是
我的测试有很多日志输出(我的意思是很多!)
Surefire插件v2.22.2
错误只发生在IDE内部，如果从命令行执行mvn命令则不会发生。
没有迹象显示Surefire插件中的任何.dump文件或Java二进制中的传统hs_err崩溃文件。
对我来说，有两件事一直是解决方案(它们是替代方案):
不使用fork:设置Surefire插件属性forkcount = 0。
增加Surefire插件属性
forkedProcessExitTimeoutInSeconds从30秒变成300秒。插件文档说，如果这个超时被击中，你会看到错误消息有一个超时在fork。我没有看到这样的错误消息，但是它一直在修复这个问题以增加这个超时值。
您可能希望使用解决方案(2)，因为分叉是可取的。
Why?
我的理论是，如果有大量的日志输出，那么在fork关闭时仍然需要进行大量的处理(特别是如果您在一个IDE中运行，该IDE捕获输出并可能为其窗口内容使用内存映射文件)。简而言之:在测试完成时，仍有大量文本等待转发到IDE中。30岁似乎还不够。
这也解释了为什么有些开发者能够发现问题，而有些开发者却不能。在测试结束时，剩下多少输出处理可能是cpu功率、磁盘速度等的函数。
如果我在这一点上是正确的-不能证明它-那么所有的建议，如重定向日志输出和降低日志级别都是IMO处理症状，而不是原因。
截至今天(2018年10月30日)，我们注意到我们的构建在Jenkins中出现了这个错误。
这个错误有点误导人，需要查看target/surefire-reports/中转储的输出，才能看到以下错误消息:
Error: Could not find or load main class org.apache.maven.surefire.booter.ForkedBooter
这让我想到了下面的SO帖子，其中提到了OpenJDK 181中一个可能的错误:Maven surefire无法找到ForkedBooter类
那篇文章中的任何一个修复都解决了我的问题。具体来说，我使用了其中之一:
从docker容器maven:3.5.4-jdk-8中的构建切换到maven:3.5.4-jdk-8-alpine
重写Spring Boot的类加载器详细信息请参见:https://stackoverflow.com/a/50661649/1228408
