Get the most out of your Maven reports

One of the most powerful features of Maven is it's reporting mechanism, also known as maven site. There are a lot of reports available which can give you an indication of the quality of your code. However if you overload yourself by adding too many reports or let the reports produce too much information everyone ignores them and the reports become useless.
In this blog I'll share which reports we chose in my current assignment and how you can customize certain Maven Reports to produce the information you want.

First of all let's start by listing the reports we chose:

Report Reason
Surefire report A bit obvious but still. Used for test results. Its important to know if there are failing tests.
Cobertura report Code coverage. Code coverage is not the holy grail, tells nothing about the quality of your tests, but can give you an estimation on how much is tested. Rule of thumb I use is that you should start investigating if it's less than 70%
JDepend report Main reason I use this is for detecting cycles within your code. Cycles make code harder maintanable and my collegue Age angry 🙂
PMD report Static Code Analysis like resources not closed. This report also includes Cyclomatic Complexity which is a good design indicator
CPD report Copy Paste Detector. Duplicate code is evil.
FindBugs report Static Code Analysis. FindBugs is better in finding Threading issues than PMD.

By using these reports I think you can get a good feeling about your project's code.


There is not much to configure about Surefire, Cobertura, JDepend and CPD so I'll focus on PMD and FindBugs


By default PMD produces a lot of information in its reports. Don't freak out if you'll see more than 500 violations per Maven project by default. The problem with this amount of issues is that the report itself becomes quite useless. No one will ever go through all 500 issues and, more important, will fix them all. A lot of these issues are style related (use of brackets), and sub optimalizations regarding performance. I only want PMD to report the important rules, the nasty bug causers like not closing streams, swallowing exceptions, threading issues etc.
At the PMD site there is comprehensive documentation available on what PMD will report about. In PMD there are rules and rulesets. Rulesets are groups of rules and other rulesets. By default PMD provides a ruleset that is packaged with the plugin. To customize this you need to create your own ruleset like described on the PMD site.

To create your own ruleset.xml that consists of other rulesets and/or rules do the following:

To add the complete ruleset String and StringBuffer to your own custom ruleset.xml:


To add all rules from the ruleset String and StringBuffer expect for AvoidDuplicateLiterals and InefficientStringBuffering do:


Then configure your maven report as follows:



FindBugs is a lot less verbose by default than PMD is. But still it can report about violations of bugs we don't care about or not report about violations we do care about. In FindBugs there are Bugs and Categories containing bugs. The FindBugs site also has a list of all possible bugs it can report about.

To include or exclude single bugs put this in your include or exclude file:


To include or exclude complete categories put this in you include or exclude file:


And to configure your report:


There is one problem left. The above configuration requires me to distribute the files containing the rules to all my projects. This is not very maintenance friendly. Instead I want these rules to be in a jar file that I can add as a maven dependency. Unfortunately the Maven FindBugs plugin can not handle classpath URL's as exclude/include file. So we need to do a little maven hack using the maven-antrun-plugin to extract the jar file containing both XML's into the target directory as follows:


Than just point to the ${}/unjar-custom-metrics" for the location of the PMD file and the FindBugs include or exclude file.


Maven 1 provided a dashboard that aggregated all the reports of your maven project in single page. As announced in this previous blogpost a Maven 2 dashboard that resembles the Maven 1 dashboard is available here I recommend to use it so you get a nice overview on one page for your project.


In order to get real value from your Maven reports you should think about which reports you choose, why you chose them and how you want to use them. If you just add the reports to your Maven site you'll probably get overloaded with information and that will hide the real important possible bugs in your system. By configuring the reports as shown in this blog you'll get more out of your Maven reports and that will eventually benefit the quality of your code.


Comments (4)

  1. Samuel Le Berrigaud - Reply

    March 31, 2008 at 2:23 am

    If you look at tracking quality of your maven 2 project I recommend Sonar ( This will work with most of the reports you mention here and provide excellent aggregation of the metrics across time for multiple projects.

  2. Pieter vd Meer - Reply

    July 9, 2008 at 3:02 pm

    As far as i know, the files defined in excludeFilterFile is searched on the classpath of the plugin.

    By define a dependency for the plugin:



    You can use the plugin and reference to a file that is within the dependency specified.

    I didnot try this for the findbugs plugin but for the pmd and checkstyle plugin this mechanism works.

    So no need for (ugly) ant scripts within the maven file.

  3. Lars Vonk - Reply

    July 10, 2008 at 11:06 am

    Hi Pieter,

    You are right. PMD supports classpath, but FindBugs doesn't. Hence the ugly script...

  4. Maven Tips | Xebia Blog - Reply

    October 25, 2008 at 2:15 pm

    [...] of noise. If you really want to benefit from them tweak them to meet your team's need. I wrote a blogpost on this topic [...]

Add a Comment