Findbugs Maven plugin - findbugs-exclude with multiple projects

Question

I've got a multiple project setup, using Maven and the Findbugs plugin. I need to exclude some files in one of the child projects, so I added it to findbugs-exclude.xml. That works when I build in the subproject.

My issue comes when I try to build at top level. Maven is not finding the findbugs-exclude.xml in the subproject. So it doesn't ignore my errors and fails because of them. I can put my findbugs-exclude.xml in the top level directory, and the exclusion works. But that's polluting the top level, and would not be looked upon favorably.

Is there a way to get the Maven plugin to use the findbugs-exclude.xml file from a subdirectory? Preferably with little to no change at the top level?

Newfashioned

Any hits on this question? I find myself with the same need, trying to get a reference to the exclude file placed in the child project from the parent pom file – Scopophilia

Nope, I still don't have a good solution. For now I'm just updating the files in both places. Violating DRY, yuck. – Newfashioned

Answer 1

One solution for this is to create a seperate project which contains the findbugs-excludes.xml and then use the dependency plugin to unpack and place it locally where it's required something like this:

<profile>
    <id>static-analysis</id>
    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <executions>
                    <execution>
                        <id>unpack-findbugs</id>
                        <phase>process-resources</phase>
                        <goals>
                            <goal>unpack</goal>
                        </goals>
                        <configuration>
                            <artifactItems>
                                <artifactItem>
                                    <groupId>com.myproject</groupId>
                                    <artifactId>my-findbugs</artifactId>
                                    <version>0.1-SNAPSHOT</version>
                                    <type>jar</type>
                                    <overWrite>true</overWrite>
                                    <outputDirectory>src/main/findbugs/</outputDirectory>
                                </artifactItem>
                            </artifactItems>
                            <!-- other configurations here -->
                            <excludes>META-INF/</excludes>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>findbugs-maven-plugin</artifactId>
                <configuration>
                    <xmlOutput>true</xmlOutput>
                    <!-- Optional directory to put findbugs xdoc xml report -->
                    <xmlOutputDirectory>target/findbugs</xmlOutputDirectory>
                    <effort>Max</effort>
                    <threshold>Low</threshold>
                    <excludeFilterFile>src/main/findbugs/findbugs-excludes.xml</excludeFilterFile>
                </configuration>
                <executions>
                    <execution>
                        <id>findbugs-run</id>
                        <phase>compile</phase>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

With this approach you can then share this exclusion file across projects if required which could be a good or a bad thing depending on how you look at it :) Also, thinking about it, if you have a dedicated findbugs project you can create different flavours of exclusions using classifiers and the use a specific classifier depending on the context. It's not perfect but it works for me.

HTH, James

Sponge

Answer 2

Here is what I am doing in my current project, it puts findbugs-exclude.xml in the parent project (which I know you don't want), but it fixes the DRY problem of maintaining it in two places. It is simpler than unpacking, but requires that the full project structure be local. (I think the unpacking solution would be useful to use the same config across many projects, as in a corporate environment.)

I store my findbugs config in parent/src/main/resources/shared/findbugs-exclude.xml, but as long as it is in parent the specific directory doesn't matter.

I then use properties to describe the location of the 'shared' directory:

<properties>
  <myproject.parent.basedir>${project.parent.basedir}</myproject.parent.basedir>
  <myproject.parent.shared.resources>${myproject.parent.basedir}/src/main/resources/shared</myproject.parent.shared.resources>
</properties>

And reference these properties when configuring findbugs in the parent:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>findbugs-maven-plugin</artifactId>
    <configuration>
      <excludeFilterFile>${myproject.parent.shared.resources}/findbugs-exclude.xml</excludeFilterFile>
    </configuration>
    ...
</plugin>

All direct child projects will now run findbugs, referencing the config file in parent. If you have multiple levels of project nesting, you will have to override the myproject.parent.basedir in the sub-parent. For example if you have parent <- sub-parent <- child, you would put :

<properties>
    <myproject.parent.basedir>${project.parent.parent.basedir}</myproject.parent.basedir>
</properties>

Redwine

Answer 3

I'm using spotbugs cause findbugs is deprecated and no longer support. I had the same issue in my project.

My maven project multi-module structure is similar to this:

parent-module:
  |
  -- sub-module-1
  |     |
  |     -- ...
  |     |
  |     --pom.xml
  |
  -- sub-module-2
  |     |
  |     -- ...
  |     |
  |     --pom.xml
  |
  -- ...
  |
  -- sub-module-n
  |     |
  |     -- ...
  |     |
  |     --pom.xml
  |
  -- ...
  |
  -- exclude-filter.xml
  |
  --pom.xml

The spotbugs configuration of parent-module:

...
<build>
    ...    
    <plugins>
        ...
        <plugin>
            <groupId>com.github.spotbugs</groupId>
            <artifactId>spotbugs-maven-plugin</artifactId>
            <version>4.0.0</version>
            <dependencies>
                <dependency>
                    <groupId>com.github.spotbugs</groupId>
                    <artifactId>spotbugs</artifactId>
                    <version>4.0.2</version>
                </dependency>
            </dependencies>
            <configuration>
                <effort>Max</effort>
                <threshold>Low</threshold>
                <includeTests>true</includeTests>
                <xmlOutput>true</xmlOutput>
                <excludeFilterFile>exclude-filter.xml</excludeFilterFile>
            </configuration>
            <executions>
                <execution>
                    <id>analyze-compile</id>
                    <phase>test-compile</phase>
                    <goals>
                        <goal>check</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
        ...
    </plugins>
...
</build>
...

No you can do mvn test-compile from parent-project or any sub-project and it will check by spotbugs for source and test-sources code issues.

Consider example: https://github.com/koresmosto/mif

Waterhouse

Answer 4

A better alternative to the accepted answer is to use maven-remote-resources-plugin. I like James' approach but then you need to tweak the clean plugin to delete the unpacked files in the src folder.

As per James' suggestion create a seperate project which contains the findbugs-excludes.xml and add the following to its pom file:

  <build>
    <plugins>
        <plugin>
            <artifactId>maven-remote-resources-plugin</artifactId>
            <version>1.5</version>
            <executions>
                <execution>
                    <goals>
                        <goal>bundle</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <includes>
                    <include>**/*.*</include>
                </includes>
            </configuration>
        </plugin>
    </plugins>
</build>

Update the pom file containing findbugs plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-remote-resources-plugin</artifactId>
    <version>1.5</version>
    <executions>
        <execution>
            <id>process-remote-resources</id>
            <goals>
                <goal>process</goal>
            </goals>
            <configuration>
                <resourceBundles>
                    <resourceBundle>com.myproject:myartifactid:version</resourceBundle>
                </resourceBundles>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>findbugs-maven-plugin</artifactId>
    <configuration>
        ...
        ...
        <excludeFilterFile>${project.build.directory}/maven-shared-archive-resources/findbugs-exclude.xml</excludeFilterFile>
        ...        
    </configuration>
</plugin>

Don't forget to change com.myproject:myartifactid:version

maven-remote-resources-plugin copies your shared files to the target folder so no need to change the default behaviour of maven-clean-plugin.

Bornu

Answer 5

If you don't have a lot of files/packages to exclude, just suppress some warnings - try using @SuppressFBWarning annotations. That should work with even multiple module projects and annotation can be added in specific projects and files where needed.

dependencies for @SuppressFBWarning

    <dependency>
        <groupId>com.google.code.findbugs</groupId>
        <artifactId>annotations</artifactId>
        <version>3.0.1</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>com.google.code.findbugs</groupId>
        <artifactId>jsr305</artifactId>
        <version>3.0.1</version>
        <scope>provided</scope>
    </dependency>

Merrileemerrili