This page contains best practices for using Clover for Maven 2 and 3.
On this page:
There are two recommended ways to utilize Clover's test optimization in a CI (Continuous Integration) environment, either using a Profile, or to run the goals directly.
NB. Clover Test Optimization will not work if you have added the maven-clover2-plugin to the default build section of the pom with an execution binding the 'instrument' goal.
The gateway plan should execute the verify phase, with the 'clover.optimize' profile activated. Example:
If your build plan is configured to do a full clean checkout before each build — you will need to ensure the Clover snapshot file is stored in a location that will not be removed between builds. The following configuration added to the
pom.xml is one option:
Beware however, that this set up will instrument your source and test files and compile them to the usual Maven output location. If you run this command:
then you will be deploying class files that have been instrumented by Clover .
Add a new build plan with the following command line:
Running Clover's test optimization locally is very advantageous. This is achieved using theprofile that can be activated like so:
Maven2 will merge any executions defined in the default build section of the pom, with those defined in a profile. It is therefore recommended practice to always use two profiles — one for test optimization and one for generating a Clover report when you generate a site. The
clover2:instrument goal forks the build lifecycle ensuring that Clover instrumented sources are kept completely separate from production sources. This also means that your tests get run twice — which is obviously not desirable in an optimized build.
Theprofile is an example of a build profile to activate when running this command:
Using separate profiles for site generation and Test Optimization is currently the recommended way to have both a site and a Test Optimization Clover build configured in the same
By default, Clover will generate a new
clover.snapshot file for each module. This means, that if you have tests in module A that cover code in module B, and you modify code in module B, the tests in module A will not be run. You can achieve the desired behaviour however, by configuring Clover to use a single
clover.snapshot for the entire project:
The clover2:setup is designed to make integration with integration and functional tests a lot simpler than using the forked lifecycle that comes with clover2:instrument. It also has the added advantage of not having to run your tests twice.
Executing clover2:setup does the following:
instrumented. Subsequent plug-ins in the build life cycle then use these locations as the source directories.
Therefore, executing the following line will instrument all source and test files, compile the instrumented source files, run all tests and then install the compiled and instrumented classes.
WARNING: It is not recommended to deploy your Clover instrumented classes to an external Maven repository.
Note: clover2:setup will automatically bind itself to the 'process-sources' phase if defined in the goals list of the plugin's executions.
If you are using cross-compilation with Groovy code, you should ensure that the
maven-clover2-plugin:setup goal runs before the GMaven Plugin's
gmaven:generateStubs goal in your
pom.xml. Otherwise, you may end up with errors when running the Clover-for-Maven 2 plugin.
Alternatively, if you run
clover2:setup directly from the
mvn command line, then this Clover goal will run before the
gmaven:generateStubs goal and you will avoid these errors when cross-compiling Groovy code.
If your terminal supports ANSI escape codes, run your Maven build with the
-Dansi.color flag. Currently a few important log messages dealing with Clover's Test Optimization will be logged in colour:
The following profiles can be used directly in the pom.xml. This avoids the need to modify the ~/.m2/settings.xml file.