Controlling which source files are instrumented

Use configuration elements to exclude and include source files from being instrumented:

<configuration>
  ...
  <includes>
    <include>...ant style glob...</include>
    <include>**/specialpackage/*.java</include>
  </includes>
  <excludes>
    <exclude>**/*Dull.java</exclude>
  </excludes>
</configuration>

Excluding tests from instrumentation

If you don't want to instrument your test classes, add the following to your pom.xml (note that this disables the reporting of per-test coverage as well as reporting of test results in Clover's HTML report):

<configuration>
  ...
  <includesTestSourceRoots>false</includesTestSourceRoots>
</configuration>

Controlling the level of instrumentation

You can define the level that Clover will instrument to (and the respective performance overhead). Valid values are 'method' level (low overhead) or 'statement' level (high overhead). The default setting is 'statement'.

Setting this to 'method' greatly reduces the performance overhead of running Clover, however limited or no reporting is
available as a result. The typical use of the 'method' setting is:

• for Test Optimization or
• for projects with a large code base (as a rough estimate of coverage).

To set this value in your pom.xml:

<configuration>
    <instrumentation>method</instrumentation>
</configuration>

To set this value on the Maven command line:

-Dmaven.clover.instrumentation=method

The setting above will result in method level only instrumentation; no statement level coverage will be available.

Configuring code contexts

Clover allows you to exclude coverage contexts from the coverage report.

To exclude try bodies and static initializer blocks:

<configuration>
  ...
  <contextFilters>try,static</contextFilters>
</configuration>

To exclude arbitrary statements or methods you can specify one or more custom contexts like so:

<configuration>
  <methodContexts>
    <main>(.* )?public static void main\(String\[\] argv\).*</main>
  </methodContexts>
  <statementContexts>
    <log>System.out.println\(.*\);</log>
    <iflog>if.*\(LOG\.is.*\).*</iflog> <!-- NB: must match entire statement, including any semicolons. -->
  </statementContexts>
</configuration>

*NB: A method context regexp must match the entire method signature. A statement context regexp must match the full statement, including the ';'.

Each one still needs to be 'enabled' via the <contextFilters/> element:

<configuration>
  ...
  <contextFilters>main,log,iflog</contextFilters>
</configuration>

If you are filtering code from your coverage reports, you can keep track of what is filtered using the custom filteredElements column. See Creating custom reports for more information.

Setting JDK Level

In most cases Clover will autodetect the JDK you are using. If you are building with a 1.5 JDK but have set the maven-compiler-plugin's source and target parameters to use a JDK version of 1.4 you will need to set the Clover JDK level to 1.4:

<configuration>
  ...
  <jdk>1.4</jdk>
</configuration>

Setting a Clover flush policy

You can set the Clover Flush Policy and interval:

<configuration>
  ...
  <flushPolicy>threaded</flushPolicy>
  <flushInterval>5000</flushInterval>
</configuration>

Setting the Clover DB location

To specify a particular location for your Clover database:

<configuration>
  <cloverDatabase>foo/clover.db</cloverDatabase>
</configuration>

and to set a location for the merged database:

<configuration>
  <cloverMergeDatabase>foo/cloverMerge.db</cloverMergeDatabase>
</configuration>

We recommend to not use absolute paths if you have large multi-module projects. The point is that instead of having small databases for each module you will have one large database, being updated multiple times.