Fork me on GitHub

Multimodule Configuration

Note: This implemented in version 2.0 of the Findbugs plugin.

Credit: This is a shameless plagiarization of the Checkstyle plugin for consistency and due to my laziness.

Configuring the Findbugs plugin for use within large multimodule projects can be done, but it requires a little setup.

This example will use a mysterious project called whizbang. This is what the structure of that project looks like:

whizbang
|-- pom.xml
|-- core
|   `-- pom.xml
|-- gui
|   `-- pom.xml
|-- jmx
|   `-- pom.xml
`-- src

Create a subproject to house the resources

We'll start by adding another sub project that will house our common configuration. Let's call it build-tools. In it we put the resources that we want to include. In this example, we will add configuration files for the Findbugs plugin. Configuration files for other plugins, like the PMD and Checkstyle plugin, can be included in the same subproject if you like. We will create another directory and call it whiz-progs and create a pom.xml file. We will move our core, gui, and jmx modules to whiz-progs.

whizbang
|-- pom.xml
|-- build-tools
|   |-- src
|   |   `-- main
|   |       `-- resources
|   |           `-- whizbang
|   |               |-- checkstyle.xml
|   |               |-- lib-filter.xml
|   |               `-- LICENSE.TXT
|   `-- pom.xml
|`-- src
|
`-- whiz-progs
    |-- pom.xml
    |-- core
    |-- gui
    `-- jmx

Tip: put the resources into a subdirectory that you can ensure will be unique and not conflict with anyone else.

Configure the top level pom

The top level pom jusr references the two modules

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example.whizbang</groupId>
  <artifactId>whizbang-parent</artifactId>
  <version>1.0</version>
  <packaging>pom</packaging>
  <name>WhizBang Parent</name>
  <modules>
    <module>build-tools</module>
    <module>modules</module>
  </modules>
</project>

Configure the other projects to build-tools

Now we can include the Findbugs configuration in the whiz-progs pom.xml.

<project>
  <modelVersion>4.0.0</modelVersion>
  <parent>
    <groupId>com.example.whizbang</groupId>
    <artifactId>whizbang-parent</artifactId>
    <version>1.0</version>
    <relativePath>../pom.xml</relativePath>
  </parent>
  <packaging>pom</packaging>
    <artifactId>whiz-progs</artifactId>
  <name>WhizBang Programs</name>
  <build>
    <extensions>
      <extension>
        <groupId>com.example.whizbang</groupId>
        <artifactId>build-tools</artifactId>
        <version>1.0</version>
      </extension>
    </extensions>
  </build>
  <reporting>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>findbugs-maven-plugin</artifactId>
        <version>3.0.6-SNAPSHOT</version>
        <configuration>
          <effort>Max</effort>
          <threshold>Low</threshold>
          <includeFilterFile>whizbang/lib-filter.xml</includeFilterFile>
        </configuration>
      </plugin>
    </plugins>
  </reporting>
  <modules>
    <module>core</module>
    <module>jmx</module>
    <module>gui</module>
  </modules>
</project>

Once you are done with that, ensure that you do not include findbugs-maven-plugin in your sub modules, as their definition and configuration, will override the top level parent pom's definition.

Based on the Findbugs plugin configuration above, the values of includeFilterFile will be resolved from the classpath. The build-tools jar was included in the classpath when it was declared as an dependency to the plugin.

Note: For the classpath reference, the build-tools was referred to as an extension and not as a plugin dependency. This is due to the fact that if it is declared as a plugin dependency, Maven will not download it from the internal repository and would just look for it in ibiblio.

Lastly, kick off a build of the site.

mvn site

Every sub project will now use the same Findbugs setup and configuration.