Blog

Get the most out of your Maven reports

29 Mar, 2008
Xebia Background Header Wave

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:

ReportReason

Surefire reportA bit obvious but still. Used for test results. Its important to know if there are failing tests.
Cobertura reportCode 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 reportMain reason I use this is for detecting cycles within your code. Cycles make code harder maintanable and my collegue Age angry 🙂
PMD reportStatic Code Analysis like resources not closed. This report also includes Cyclomatic Complexity which is a good design indicator
CPD reportCopy Paste Detector. Duplicate code is evil.
FindBugs reportStatic 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.
Configuring
There is not much to configure about Surefire, Cobertura, JDepend and CPD so I’ll focus on PMD and FindBugs
PMD.
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:

  maven-pmd-plugin
  2.3

    5

      ${basedir}/src/main/config/custom-pmd-rules.xml

FindBugs
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:

  org.codehaus.mojo
  findbugs-maven-plugin
  1.1.1

    true
    Default
    ${basedir}/src/main/config/findbugs-excludes.xml

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:

  org.apache.maven.plugins
  maven-antrun-plugin

      compile
      process-resources

        run

      com.xebia.blog.example
      custom-metrics
      1.0

Than just point to the ${project.build.directory}/unjar-custom-metrics" for the location of the PMD file and the FindBugs include or exclude file.
Dashboard
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 mojo.xebia.com/maven-dashboard-plugin/. I recommend to use it so you get a nice overview on one page for your project.
Conclusion
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.
Lars

Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts