Как я могу заставить Хадсона сгенерировать отчет Findbugs без сбоев из-за исключения?

Question

Обновление

Начиная с версии 4.3 подключаемого модуля Hudson Findbugs это больше не является проблемой

Окончание обновления

В качестве примера моей проблемы я пытаюсь построить следующий проект 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 ошибках нет ошибок):

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

Я использую Hudson с проектом в стиле maven2. Работа нацелена на простого родителя с целями

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)

Информация о версии:

• Maven 2.2.1
• Java 1.5.0_22
• Hudson 1.341 (также найденный на 1.339), работающий внутри JBoss 4.0.5.GA (та же ошибка на 4.2.2.GA и 5.1.0.GA)
• Плагин Maven FindBugs 2.3
• Плагин Hudson FindBugs 4.1

Есть идеи как это исправить?

Answer 1

Согласно FAQ FindBugs, эта проблема возникает, когда используется неправильная версия Apache BCEL (см. Q2: Когда я нажимаю кнопку «Найти ошибки!», Я получаю NoSuchMethodError или VerifyError ) , В вашем случае я подозреваю, что maven-findbugs-plugin получает библиотеку BCEL от JBoss из-за какой-то неясной проблемы с загрузкой классов. Есть некоторые очень похожие ошибки в Jira Гудзона, например HUDSON-5134 (также затронут плагин hudson findbugs).

Насколько я понимаю, эта проблема была введена недавно (в v1.338) и, даже если есть обходной путь, она является ошибкой Гудзона (это регрессия , это не проблема с JBoss).

Теперь у вас есть два решения IMO:

• Используйте версию Hudson, предшествующую v1.338 (регрессия была сообщена для этой версии), но использование старой версии и ее сохранение, безусловно, не является жизнеспособным решением.
• Удалите или замените bcel.jar JBoss (в server/SERVERNAME/lib) версией, используемой плагином maven-findbugs-plugin (см. зависимостей ). Я не могу сказать, как именно это повлияет на JBoss (если вы удалите его, похоже, вы потеряете возможность запускать JBoss в режиме отладки, но я не могу сказать, все ли будет работать нормально, если вы его замените) .

Что бы вы ни делали, создайте новый выпуск Jira (http://issues.hudson -ci.org / ), поскольку этот является регрессией в Гудзоне . Они пометили HUDSON-5134 как «Не исправлю», потому что есть обходной путь, но я не думаю, что связываться с библиотеками JBoss - это хорошее решение (я повторяюсь, но это Хадсон ошибка). Таким образом, настаивание и информирование разработчиков Hudson о том, что эта проблема затрагивает других пользователей, поможет всему сообществу (по крайней мере, я на это надеюсь).

Answer 2

Как указывает Паскаль, есть аналогичная ошибка - HUDSON-5134 - и эта ошибка указывает на поведение, начатое с выпуском Hudson 1.338. Поскольку Hudson выпускает один раз в неделю, может быть трудно определить, какая версия внесла ошибку. Я заметил, что было внесено изменение, связанное с загрузкой классов, с Hudson версия 1.337 ( HUDSON-5048 ), и я подозреваю, что это вызывает проблему, но у меня нет прямых доказательств того, что тот.

Но это, вероятно, означает, что вам нужно откатиться до 1.337 или более ранней, чтобы избежать этой проблемы.

Answer 3

Другие предоставленные ответы лучше, но можно добавить одну альтернативу: используйте Ant или командный файл для создания отдельного шага сборки, который не заботится о том, что шаг FindBugs не удался. Плагин Hudson все еще можно использовать для отображения результатов.