如何让 Hudson 生成 Findbugs 报告而不会因异常而失败?

发布于 2024-08-18 12:46:28 字数 3698 浏览 1 评论 0原文

更新

从 Hudson Findbugs 插件版本 4.3 开始,这不再是问题

结束更新

作为我的问题的一个示例,我正在尝试构建以下项目 http://www.sonatype.com/books/mvnex-book/reference/ multimodule.html

我将以下内容添加到 simple-parent/pom.xml

<reporting>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>findbugs-maven-plugin</artifactId>
      <version>2.3</version>
      <configuration>
         <findbugsXmlOutput>true</findbugsXmlOutput>
         <findbugsXmlWithMessages>true</findbugsXmlWithMessages>
         <xmlOutput>true</xmlOutput>
      </configuration>
    </plugin>
  </plugins>
</reporting>

并将以下内容添加到 simple-weather/pom.xml 和 simple-webapp/pom.xml

<reporting>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>findbugs-maven-plugin</artifactId>
    </plugin>
  </plugins>
</reporting>

我将以下可怕的 equals 方法插入到其中一个类中让 FindBugs 生成一些问题(因为 0 个 bug 没有错误):

public boolean equals(Object o) { return true; }

我正在将 Hudson 与 maven2 风格的项目一起使用。这项工作针对的是简单父级 pom,其目标是

clean site

我得到以下异常:

[INFO] Generating "FindBugs Report" report.
[java] Warnings generated: 2
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot inherit from final class
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.VerifyError: Cannot inherit from final class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch2(RemoteClassLoader.java:370)
at sun.reflect.GeneratedMethodAccessor594.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
at hudson.remoting.Request$2.run(Request.java:270)
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:651)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)

Version info:

  • Maven 2.2.1
  • Java 1.5.0_22
  • Hudson 1.341 (also found on 1.339) running inside JBoss 4.0.5.GA (same error on 4.2.2.GA 和 5.1.0.GA)
  • Maven FindBugs 插件 2.3
  • Hudson FindBugs 插件 4.1

关于如何解决这个问题有什么想法吗?

Update

As of Hudson Findbugs plug-in version 4.3 this is no longer an issue

End Update

As an example of my problem, I'm trying to build the following project http://www.sonatype.com/books/mvnex-book/reference/multimodule.html

I added the following to simple-parent/pom.xml

<reporting>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>findbugs-maven-plugin</artifactId>
      <version>2.3</version>
      <configuration>
         <findbugsXmlOutput>true</findbugsXmlOutput>
         <findbugsXmlWithMessages>true</findbugsXmlWithMessages>
         <xmlOutput>true</xmlOutput>
      </configuration>
    </plugin>
  </plugins>
</reporting>

And the following to simple-weather/pom.xml and simple-webapp/pom.xml

<reporting>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>findbugs-maven-plugin</artifactId>
    </plugin>
  </plugins>
</reporting>

I inserted the following horrible equals method into one of the classes to have FindBugs generate some issues (as there is no error on 0 bugs):

public boolean equals(Object o) { return true; }

I'm using Hudson with a maven2 style project. The job is aimed at the simple-parent pom with the goals

clean site

I get the following exception:

[INFO] Generating "FindBugs Report" report.
[java] Warnings generated: 2
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot inherit from final class
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.VerifyError: Cannot inherit from final class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch2(RemoteClassLoader.java:370)
at sun.reflect.GeneratedMethodAccessor594.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
at hudson.remoting.Request$2.run(Request.java:270)
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:651)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)

Version info:

  • Maven 2.2.1
  • Java 1.5.0_22
  • Hudson 1.341 (also found on 1.339) running inside JBoss 4.0.5.GA (same error on 4.2.2.GA and 5.1.0.GA)
  • Maven FindBugs plugin 2.3
  • Hudson FindBugs plugin 4.1

Any ideas on how to fix this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

2024-08-25 12:46:28

根据 FindBugs FAQ,当使用错误版本的 Apache BCEL 时会出现此问题(请参阅 Q2 :当我单击“查找错误!”按钮时,我收到 NoSuchMethodError 或VerifyError)。就您而言,我怀疑 maven-findbugs-plugin 正在从 JBoss 获取 BCEL 库,因为存在一些模糊的类加载问题。 Hudson's Jira 中也存在一些非常相似的错误,例如 HUDSON-5134 ( hudson findbugs 插件也受到影响)。

我的理解是这个问题最近被引入(在 v1.338 中),即使有解决方法,它也是一个 Hudson bug(它是一个回归,这不是 JBoss 的问题)。

现在,我有两种解决方案:

  • 使用 v1.338 之前的 Hudson 版本(报告了该版本的回归),但使用旧版本并坚持使用它肯定不是一个真正可行的解决方案。
  • 删除 JBoss 的 bcel.jar(位于 server/SERVERNAME/lib 中),或将其替换为 maven-findbugs-plugin 使用的版本(请参阅 依赖项)。我无法确切地说这将如何影响 JBoss(如果删除它,似乎您将失去在调试模式下运行 JBoss 的能力,但我不能说如果替换它,是否一切都会正常工作) 。

无论您要做什么,请创建一个新的 Jira 问题 (http://issues.hudson-ci.org/ ),因为这是 Hudson 的回归。他们已将 HUDSON-5134 标记为“不会修复”,因为一个解决方法,但我不认为弄乱 JBoss 库是一个好的解决方案(我重复一遍,但这是一个 Hudson 错误)。因此,坚持并让 Hudson 开发人员知道其他用户受到此问题的影响将有助于整个社区(至少我希望如此)。

According to the FindBugs FAQ, this problem occurs when the wrong version of Apache BCEL is being used (see Q2: When I click the "Find Bugs!" button, I get a NoSuchMethodError or VerifyError). In your case, I suspect that the maven-findbugs-plugin is getting the BCEL library from JBoss because of some obscure classloading issue. There are some very similar bugs in Hudson's Jira, e.g. HUDSON-5134 (the hudson findbugs plugin is also affected).

My understanding is that this problem has been introduced recently (in v1.338) and, even if there is a workaround, it is an Hudson bug (it is a regression, it's not a problem with JBoss).

Now, you have IMO two solutions:

  • Use a version of Hudson anterior to v1.338 (the regression was reported for this version) but using an old version and sticking with it is certainly not really a viable solution.
  • Remove or replace the bcel.jar of JBoss (in server/SERVERNAME/lib) with the version used by the maven-findbugs-plugin (see dependencies). I'm not able to say how this will affect JBoss exactly (If you remove it, it seems that you will loose the ability to run JBoss in debug-mode but I can't say if everything will work fine if you replace it).

Whatever you'll do, please create a new Jira issue (http://issues.hudson-ci.org/) as this is a regression in Hudson. They have marked HUDSON-5134 as "Won't fix" because there is a workaround but I don't think that messing with JBoss libraries is a good solution (I'm repeating myself but this is a Hudson bug). So, insisting and letting Hudson developers know that other users are affected by this problem will help all the entire community (at least, I hope so).

剧终人散尽 2024-08-25 12:46:28

提供的其他答案更好,但添加一种替代方法:使用 Ant 或批处理文件创建一个单独的构建步骤,该步骤不关心 FindBugs 步骤失败。 Hudson插件仍然可以用来显示结果。

The other answers provided are better, but one alternative to add: use Ant or batch file to create a separate build step that doesn't care that the FindBugs step failed. The Hudson plug-in can still be used to display the results.

晨曦÷微暖 2024-08-25 12:46:28

正如 Pascal 指出的那样,存在一个类似的错误 - HUDSON-5134 -该错误表明该行为从 Hudson 版本 1.338 开始。由于 Hudson 每周发布一次,因此很难确定哪个版本引入了错误。我注意到 Hudson 版本 1.337 发布了与类加载器相关的更改(HUDSON-5048),我怀疑这是导致问题的原因,但我没有直接证据。

但这可能意味着您需要回滚到 1.337 或更早版本以避免此问题。

As Pascal points out, there is a similar bug filed - HUDSON-5134 - and that bug indicates the behavior started with Hudson release 1.338. Since Hudson releases once a week, it can be difficult to pin down which version introduced a bug. I notice there was a classloader related change released with Hudson version 1.337 (HUDSON-5048), and I suspect that is causing the problem here, but I don't have direct evidence of that.

But that likely means you need to roll back to 1.337 or earlier to avoid this problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文