maven findbugs“高水位线”

我在maven findbugs跟踪器中提出了这个问题(参见 http://jira.codehaus.org/browse/MFINDBUGS-115

作为提出这个问题的一部分,我已经编写了一个代码,并提交了一个补丁。在我们的大型多模块项目中,我们成功地运行了这个补丁程序。

您可以按照findbugsmaven插件站点上的说明同步代码并应用修补程序,或者希望修补程序或其派生版本可以被插件的未来版本所接受。

Findbugs(以及我所知道的所有其他代码度量插件)生成 an XML file

它将使用一个公共的解析器接口,您必须为每个度量插件实现这个接口。配置如下:

<plugin>
    <groupId>com.yourcompany</groupId>
            <artifactId>your-plugin-id</artifactId>
            <version>1.0</version>
            <executions>
                    <execution>
                        <id>readmetrics</id>
                        <phase>process-classes</phase>
                        <goals>
                            <goal>analyse-metrics</goal>
                        </goals>
                    </execution>
             </executions>
             <configuration>
                  <metrics>
                      <metric>
                          <type>findbugs</type>
                          <file>${project.reporting.outputDirectory}/findbugs/output.xml</file>
                      </metric>
                      <metric>
                          <type>checkstyle</type>
                          <file>${project.reporting.outputDirectory}/checkstyle/output.xml</file>
                      </metric>
                      <metric>
                          <type>pmd</type>
                          <file>${project.reporting.outputDirectory}/pmd/output.xml</file>
                      </metric>
                  </metrics>
              </configuration>
        </plugin>

在我看来,FindBugs的情况有点特殊:违规不仅仅是表面的,它们可能是真正的bug,因此应该被修复,至少是高优先级的bug(即当使用 High 阈值)。

以防万一,我们遵循类似的模式(我们对done的定义包括 不增加技术债务 Sonar 以及它的 time machine 跟踪指标演变(我们跟踪每日演变)。它对我们很有效,即使它没有失败的构建那么强大。

有趣的是你提到这一点,因为我正在为我的雇主工作。我们已经剥离了一个开源项目来完成这项工作,叫做 dybdob ; 事实上 非常地 一个正在进行的工作,现在回购协议中的代码是相当可怕的,非常硬编码/黑客。然而,这个计划或多或少是按照seanizer的建议来做的:解析XML,保持计数,如果增加的话就会失败。

我实现的第一件事(同样是:硬编码、黑代码和非文档化)是一个插件,它实际计算从构建中发出的javac编译器警告,如果警告数量增加,则中断构建。这是现在的工作,我目前正在研究findbugs,checkstyle,和pmd警告并行。

如果你有兴趣帮忙(或者只是想看看它是如何发展的),请给我留言。