Jenkins没有显示maven编译器错误 [英] Jenkins not showing maven compiler errors
问题描述
在Jenkins构建我们的多模块maven 3项目时，如果出现构建错误，我们会收到maven编译器插件失败的神秘消息。这才刚刚开始在上周内发生：
When building our multi-module maven 3 project in Jenkins, if there's a build error we get this cryptic message that the maven compiler plugin failed. This only just started happening within the last week:
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11:22.340s
[INFO] Finished at: Fri Feb 10 09:44:02 CET 2012
[INFO] Final Memory: 171M/318M
[INFO] ------------------------------------------------------------------------
mavenExecutionResult exceptions not empty
message : Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project me.activity.impl: Compilation failure
cause : Compilation failure
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) on project me.activity.impl: Compilation failure
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:104)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure
at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:516)
at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:114)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 27 more
Maven schlug mit Fehlern fehl.
An attempt to send an e-mail to empty list of recipients, ignored.
从命令行构建时，我们得到正常的构建错误：
When building from the command-line we get the normal build errors:
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5:24.906s
[INFO] Finished at: Fri Feb 10 08:17:31 EST 2012
[INFO] Final Memory: 173M/328M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile) on project me.activity.impl: Compilation failure: Compilation failure:
[ERROR] \p4views\VM\Base\main\modules\activity\impl\src\main\java\com\sap\me\activity\impl\ExtensionConfigurationService.java:[1018,12] cannot find symbol
[ERROR] symbol : class ActivityRuntimeType
[ERROR] location: class com.sap.me.activity.impl.ExtensionConfigurationService
[ERROR] \p4views\VM\Base\main\modules\activity\impl\src\main\java\com\sap\me\activity\impl\ExtensionConfigurationService.java:[200,16] cannot find symbol
[ERROR] symbol : class ActivityRuntimeType
[ERROR] location: class com.sap.me.activity.impl.ExtensionConfigurationService
[ERROR] \p4views\VM\Base\main\modules\activity\impl\src\main\java\com\sap\me\activity\impl\ExtensionConfigurationService.java:[234,16] cannot find symbol
[ERROR] symbol : class ActivityRuntimeType
[ERROR] location: class com.sap.me.activity.impl.ExtensionConfigurationService
[ERROR] \p4views\VM\Base\main\modules\activity\impl\src\main\java\com\sap\me\activity\impl\ExtensionConfigurationService.java:[263,16] cannot find symbol
[ERROR] symbol : class ActivityRuntimeType
[ERROR] location: class com.sap.me.activity.impl.ExtensionConfigurationService
[ERROR] \p4views\VM\Base\main\modules\activity\impl\src\main\java\com\sap\me\activity\impl\ExtensionConfigurationService.java:[294,20] cannot find symbol
[ERROR] symbol : class ActivityRuntimeType
[ERROR] location: class com.sap.me.activity.impl.ExtensionConfigurationService
[ERROR] \p4views\VM\Base\main\modules\activity\impl\src\main\java\com\sap\me\activity\impl\ExtensionConfigurationService.java:[311,16] cannot find symbol
[ERROR] symbol : class ActivityRuntimeType
[ERROR] location: class com.sap.me.activity.impl.ExtensionConfigurationService
[ERROR] \p4views\VM\Base\main\modules\activity\impl\src\main\java\com\sap\me\activity\impl\ExtensionConfigurationService.java:[1023,47] cannot find symbol
[ERROR] symbol : variable ActivityRuntimeType
[ERROR] location: class com.sap.me.activity.impl.ExtensionConfigurationService
[ERROR] \p4views\VM\Base\main\modules\activity\impl\src\main\java\com\sap\me\activity\impl\ExtensionConfigurationService.java:[1025,67] cannot find symbol
[ERROR] symbol : variable ActivityRuntimeType
[ERROR] location: class com.sap.me.activity.impl.ExtensionConfigurationService
[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/MojoFailureException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :me.activity.impl
我们在本地版本中都使用maven-3.0.4和詹金斯。詹金斯版本是1.3ish，但我升级到1.450，看看问题是否会消失 - 事实并非如此。这发生在我们从maven-2.2.1转移到maven-3.0.4的时候，但是我可以发誓（虽然我没有证据）我在Jenven升级之后就得到了正常的构建错误，所以我不要以为就是这样，但这是我能想到的唯一一个会导致这种变化的变化。编译器插件版本是2.0.2。
We're using maven-3.0.4 both for local builds and on Jenkins. Jenkins version was 1.3ish, but I upgraded to 1.450 to see if the issue would go away - it didn't. This happened about the time we moved from maven-2.2.1 to maven-3.0.4, but I could swear (although I don't have evidence) that I was getting normal build errors on Jenkins just after the maven upgrade, so I don't think that's it, but it's the only change I can think of that would cause this. The compiler plugin version is 2.0.2.
我看到类似的帖子这里但他的问题与eclipse构建有关，而不是Jenkins。
I saw a similar posting here but his issue had to do with eclipse builds, not Jenkins.
推荐答案
得到 答案，这可能不适合你，因为它看起来很依赖很多东西和情况，但我怀疑这对大多数人来说确实有用。
Got an answer, which may not work for you as it seems rather dependent on many things and circumstances, BUT I suspect it is indeed relevant for most people here.
（如果你不关心我如何解决这个问题，请跳过我的设置，但这对你的设置有帮助。解决方案1
一个积极开发的项目的当前工作目录开始吐出今天显示此行为的日志，此时暂时没有错误。我使用的是Windows 7，Maven 3.0.4，编译器插件2.4和java（c）1.6.0_31。
Current working-directory of an actively developed project started to spit out logs showing this behavior today, when there had been no errors for a while. I was using Windows 7, Maven 3.0.4, compiler plugin 2.4, and java(c) 1.6.0_31.
当到达特定的子模块时，maven会吐输出一些错误消息并使构建失败，除了错误消息不相关（报告使用专有的 com.sun。* API）并且没有实际编译的迹象错误。
When reaching a specific sub-module, maven would spit out some error messages and fail the build, except the error messages were unrelated (reporting use of proprietary com.sun.* APIs) and there would be no sign of an actual compilation error.
此时我发现这个帖子，我也试试用不同的java版本和maven-compiler-plugin版本重新构建。这是有趣的部分：
At this point I find this thread, and I also try to re-build with different java versions and maven-compiler-plugin versions. Here's the fun part:
- 使用compiler-plugin 2.5，我会遇到类似的问题，并且没有有效的错误报告;
- 使用编译器插件2.3，我会得到一个类似的问题一个无意义的错误报告抱怨缺少包 （现在和类路径上存在！ ）;
- 使用编译器插件2.3.2，我会得到一个类似的问题一个无意义的错误报告抱怨缺少包 （现在和类路径中存在！） 但是**在测试类的模块编译</ strong>中的不同点**（之前它发生在正常的类中） '汇编）。
- with compiler-plugin 2.5, I'd get a similar issue, and no valid error report;
- with compiler plugin 2.3, I'd get a similar issue with a nonsensical error report complaining about a missing package (that is present and on classpath, though!);
- with compiler plugin 2.3.2, I'd get a similar issue with a nonsensical error report complaining about a missing package (that is present and on classpath, though!) BUT ** at a different point **in the test-classes' compilation of the module (previously it happened during the normal classes' compilation).
变得可疑，我切换到另一个目录，干净地检查项目并重新构建所有内容。
Getting suspicious, I switched to another directory with a clean checkout of the project and re-built everything.
一切正常 FINE 。困惑和绝望在这里。
Everything worked FINE. Puzzlement and despair here.
所以我意识到我正在另一个巨大和复杂类中工作工作区，在故障模块中。我的意思是相当庞大，复杂，写得相当糟糕。让你告诉你的老板的野兽类型请不要让我触摸这个，这使得你的DELETE键每当你在IDE中遇到不幸时都会发痒。事实上，这个东西看起来非常像一个黑暗的margic实验的后代和奇怪的不道德的生物研究，你想知道它是不是来自RTC Wolfenstein或Doom，如果对手是一些代码。这个类你不想在晚上独自编写代码，并且Sonar悄悄地报告了近1000个代码质量违规，包括复杂性索引让你想知道PMD，JDepend和其他工具实际上是否都没有同时中风）。
So I realized I was working on a rather huge and complex class in the other workspace, in the faulty module. And I do mean rather huge, complex, and fairly poorly written. The type of beast that makes you tell your boss "please don't make me touch this" and that makes your DELETE key tickle you every time you have the misfortune of running across it in your IDE. In fact, this thing looks so much like the offspring of a dark margic experiment and weirdly unethical bioresearch that you wonder if it didn't come right out of RTC Wolfenstein or Doom, if the antagonists were bits of code. The class you don't want to be left alone to code on at night, and for which Sonar quietly reports close to 1000 code quality violations, including complexity indexes that make you wonder if PMD, JDepend and other tools are not actually all having a stroke at the same time).
但是我离题了......
But I digress...
我把它复制到这个干净的和看似工作的工作区（幸运的是，它没有影响其他文件，所以它很简单：只需复制）。
I copied it over to this clean and seemingly working workspace (luckily for me, it didn't impact other files, so it was rather simple to do: just copy over).
然后我用Maven重建当它再次到达包含该文件的模块时它会变得一团糟，除非这次它打印出一个加载错误，并且堆栈跟踪已经结束。所以我想尝试重新运行相同的构建，这次将输出保存到日志文件中以便仔细观察（这是新奇怪的东西，因为到目前为止还不够奇怪）...再次没有显示任何错误。
Then I rebuild with Maven and it gets all cranky when it reaches the module containing this file again, except this time it prints out a load of errors a stacktrace that nevers ends. So I want to try to re-run the same build, this time saving the output to a log file to have a closer look and (here's the new odd thing, because so far that wasn't bizarre enough) ... it again doesn't show any error.
所以，我认为某事显然非常讨厌，对于 javac 来说看起来像堆栈溢出的东西，并寻找我第一次在我的日志中看到的堆栈跟踪。这里有一大块（因为我怀疑有些人可能会遇到这个问题并且发现这个答案很有用）：
So, I'm figuring something is obviously very nasty, for javac to go belly up with what looks like a stack overflow, and look for the bit of stacktrace I could see in my log the first time around. Here's a chunk of it (as I suspect some may come across this and find this answer useful):
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:377)
[ERROR] at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1241)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1210)
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1799)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1522)
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.attribExpr(Attr.java:377)
[ERROR] at com.sun.tools.javac.comp.Attr.visitApply(Attr.java:1241)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1210)
[ERROR] at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:360)
[ERROR] at com.sun.tools.javac.comp.Attr.visitSelect(Attr.java:1799)
[ERROR] at com.sun.tools.javac.tree.JCTree$JCFieldAccess.accept(JCTree.java:1522)
Google很好地指出我......当然是StackOverflow：）
And Google nicely points me to... StackOverflow, of course :)
我可以看到一个容易尝试的事情（见下文）。
Where I can see an easy thing to try (see below).
当然，如果堆栈跟踪出现在所有情况下并且在所有情况下都显示出明显的StackOverflowException，那么这将是更容易进行故障排除。特别是考虑到我已经看到了这个错误，并且知道这意味着什么，但是当你**看不到错误时，很难找到它。
Of course, this would have been way easier to troubleshoot, had the stacktrace appeared in all situations and in all cases, and shown the obvious StackOverflowException. Especially considering I have otherwise already seen this error and know what it means, but it's a hell of a lot harder to figure out when you **can't see* the error.
不确定为什么Maven吞下那个，但是可能 javac 只是在没有通知的情况下坠毁而且日志管理中出现了问题没有正确刷新。
Not sure why Maven swallowed that one, but maybe javac simply crashed without notice and there's a screw-up in the log management and it doesn't get flushed out properly.
这也可以解释为什么这个bug相对随机发生：它会受到你的硬件设置的影响，以及对类的轻微改变 javac 给予处理。
That would also explain why this bug happens relatively randomly: it would be impact by your hardware settings, and slight changes to the classes javac is given to process.
那么，现在是什么???好吧，如果在java尝试处理你的代码时有一个疯狂的堆栈溢出异常或OutOfMemoryException，显然你需要做类似于下面解释的事情......
So, now what??? Well, if there's a crazy stack overflow exception or an OutOfMemoryException when java tries to process your code, obviously you need to do something akin to what's explained below...
升级内存设置。最简单的方法是使用之类的（对于类似bash的shell）：
Upgrade your memory settings. Simplest way is with something like (for a bash-like shell):
export MAVEN_OPTS="-Xss1024k -Xms512m -Xmx1024m"
BEWARE ：这些设置取决于你的平台的硬件，显然（和你的shell）。
BEWARE: These settings will depend on your platform's hardware, obviously (and on your shell).
在我的情况下，我实际上曾经有：
In my case, I actually used to have:
export MAVEN_OPTS="-Xss128k -Xms384m -Xmx384m"
...因为我有一个非常繁重的项目和一个不那么具有内存功能的工作站，所以我需要从中挤出每一点RAM才能运行多个Eclipse实例，多个应用程序服务器等等......所以我的JAVA_OPTS，ANT_OPTS和MAVEN_OPTS设置了很多选项，包括这些选项。
... because I have a pretty heavy project and a not so memory-capable workstation, so I need to squeeze every bit of RAM I can out of it to have multiple Eclipse instances running, multiple application servers, etc... So my JAVA_OPTS, ANT_OPTS and MAVEN_OPTS are set with a bunch of options, including these.
这不一定是你想要的!! 默认Windows上64位JVM的xss实际上是1024，所以我使用的东西要小得多。我只是说它，因为它可能在同样的情况下帮助其他人。尝试相应地提高它并合理地为你配置。
This is not necessarily what you want!! The default xss for a 64 bits JVM on Windows is actually 1024, so I use something considerably smaller. I'm just saying it as it may help others in the same situation. Try to raise it accordingly and sensibly for you configuration.
所以，最终，为了解决我的项目中的这个特殊问题，我不得不将上面的内容更改为：
So, eventually, to fix this particular issue in my project, I had to change the above to:
export MAVEN_OPTS="-Xss256k -Xms384m -Xmx384m"
现在一切都很好用。
也许其他一些事情对你来说有所不同。请告诉我。
你知道什么比摆弄别人不会知道的内存设置更好，而且可能没有机会，这会让你的构建变得不那么便携？ [观众在这里发出尖叫声]
You know what's better than fiddling with memory settings that others won't know to fiddle with and may not have the chance to, and that make your builds less portable? [audience screams here]
你重构出那个令人讨厌的类的地狱 $ c> javac 为妈妈哭泣。
就这么简单。没有数千和数千行长类，有疯狂的静态初始化器，超长的方法和类似的东西。如果您的代码看起来很复杂，那么对于差的 javac 也是如此。
It's that simple. No thousands and thousands of lines long classes, with crazy static initializers, super long methods and stuff like these. If your code looks complicated to you, it sure does for poor javac as well.
保存 javac 今天处理：重构您的代码!!
Save a javac process today: refactor your code!!
这篇关于Jenkins没有显示maven编译器错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
