I’ve talked about FindBugs a couple times; here and here. What I haven’t talked about is how you remove “bugs” that it finds that are not relevant in your context. So I’ll do that not — from within Maven 2 for extra points.

Tuning FindBugs is done thought a specially formatted xml file (root element FindBugsFilter). This page of the FindBugs explains it in pretty good detail. Of all the methods now, I prefer the following:

<!-- A method with an open stream false positive. -->
<Match>
    <Class name="com.foobar.MyClass" />
    <Method name="writeDataToFile" />
    <Bug pattern="OS_OPEN_STREAM" />
</Match>

The upside of this is that it is very narrow. The last thing you want to do is accidently tune out a bug that someone creates later in the release that is relevant. The downside is that creating this file might take a bit of time in a large, legacy project.

We’re using the FindBugs Maven Plugin to integrate FindBugs with Maven. I had originally thought of putting the exclude file into ${basedir}/src/test/static/resources, but everything there gets copied during the test goal and put into the classpath which we don’t need. Instead, I added the maven-ish

<excludeFilterFile>${basedir}/src/test/static/findbugs.exclude</excludeFilterFile>

to my plugin’s configuration. As I tune the other static analysis tools, I’ll be putting their exclude files in the same dir.

One final thing about tuning out results. Even though this tuned out thing at the specific method level, the possibility of accidently tuning out something important increases with the size of the method. (Which is a good argument for keeping methods small). I would recommend that you comment out the excludeFilterFile element every couple weeks for a bit just to be sure the net hasn’t been cast too wide.