Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Maven Site Reports

The parent POM shared by all the Java-based project defines a set of reports that can be generated.

Generating and Locating the Reports

In order to generate the reports run the following in either the project directory, for monolithic projects, or the *-parent directory, for multi-module projects:

mvn -Prelease site

The results are then located in target/site directory. You can use the -DskipTests option when executing the command to skip unit tests if you prefer.

Available Reports

Java Cross Reference

This report generates an HTML-ized view of the Java code allowing URLs that reference particular lines, classes, fields, and methods. For multi-module projects you can also find an aggregation of all the per-module reports.

Most of the following reports build on this one.

Javadoc

This report generates the standard HTML Javadoc files. For multi-module projects you can also find an aggregation of all the per-module reports.

Cobertura Unit Test Coverage

This report provides information on what code has been exercised by the unit tests. It will show how many times each line has been hit and what lines/methods/classes haven't been covered. Such information is useful for ensuring that at least a minimum amount of unit testing is done.

There are a couple things to note, however:

  • Just because a some code has been executed during a unit test does not it isn't buggy. The test may not have covered all possible types of input. Hopefully this is obvious, but for any pointy-haired boss reading this we state this explicitly.
  • The coverage reports do not really understand certain language constructors. This includes assert statements and the private constructors used in our support classes.

Java NCSS Statistics

This report provides metrics about the source code. This includes things like number of lines of code and comments and cyclomatic complexity. The former is useful for ensuring that all our classes/methods have javadoc. The ratio between the two should be about 1:1, if the amount of javadoc lines is significantly less then the javadoc probably isn't descriptive enough to be useful. The later is useful flagging potentially overly-complicated code. Our checkstyle configuration within Eclipse will also flag this.

  • No labels