The difference (in milliseconds) that a -clover classified artifact can have to a non-clover classified artifact.

If the -clover classified artifact is more than cloveredArtifactExpiryInMillis older than the non-clover classified artifact, then the non-classified artifact will be used.

This setting defaults to 2000.

The configuration for distributed coverage collection by Clover.

If present, default values will be used and coverage will be collected across JVMs.

Optional nested elements (and their defaults) of distributedCoverage are:

• host - the host name of the JVM running the tests. default: localhost
• port - the port that Clover can bind to in the host JVM. default: 1198
• numClients - the number of clients expected to attach to the Test JVM. The test JVM will wait until numClients have connected before continuing. default: 0
• timeout - the amount of time to wait for a response from a remote JVM before shunning it. default: 5000
• retryPeriod - the amount of time a client should wait between reconnect attempts. default: 1000

By default, Clover Maven Plugin generates the ${java.io.tmpdir}/grover*.jar file during setup, which is next being added as the dependent artifact to the build. As the file has generated, unique name and the jar is not being removed at the end of the build, these files can litter the temporary directory.

By setting this parameter you can:

a) specify constant file name for generated artifact,

b) choose location different than ${java.io.tmpdir}.

However, you must ensure that:

a) grover.jar will not be deleted till end of the build (for example don't put into ./target directory and next run mvn clover:setup clean)

b) grover.jar will not be shared among builds with different Clover Maven Plugin versions used (for example if ProjectA uses Clover v 3.1.8 and ProjectB uses Clover v 3.1.9 then they shall have different groverJar locations defined)

Till 3.1.11: whether the Clover plugin should instrument all source roots (for example src/main/java, src/main/groovy, target/generated-sources, so including the generated sources) or whether it should only instrument the main source root (usually src/main/java).

Since 3.1.12: whether the Clover plugin should instrument all source roots (for example src/main/java, src/main/groovy, target/generated-sources, so including the generated sources) or whether it should instrument non-generated source roots (i.e. all roots except target/generated-sources/*)

Define whether lambda functions shall be instrumented: Valid values are:

• none - do not instrument lambda functions (note: statements inside lambdas will become a part of a parent function)
• expression - instrument only expression-like lambdas, e.g. (a,b) -> a + b
• block - instrument block lambdas, e.g. () -> { foo(); }
• all_but_reference - instrument lambdas written in any form except method references, e.g. Math::abs
• all - instrument all forms of lambda functions

Default is 'all' for 3.2.2-4.0.2 and 'none' since 4.0.3.

IMPORTANT: Due to Clover's restrictions related with code instrumentation and javac compiler's type inference capabilities, you may get compilation errors when expression-like lambda functions are passed to generic methods or types. In such case disable instrumentation of expression-like form (i.e. use the 'none' or 'block' setting). See the Java 8 code instrumented by Clover fails to compile Knowledge Base article for more details.

The level to instrument to. Valid values are 'method' or 'statement'. Default is 'statement'.

Setting this to 'method' greatly reduces the overhead of enabling Clover, however limited or no reporting is available. The current use of setting this to method is for Test Optimization only.

Which Java language level Clover shall use to parse sources. Valid values are:

• 1.7 (String in switch, try with resources, binary literals, underscores in literals)
• 1.8 (lambda expressions, default methods in interfaces)
• 9 / 1.9 (module-info.java)

By default Clover instruments using the highest language level supported.

Specifies the custom method contexts to use for filtering specific methods from Clover reports.

<main>public static void main\(String args\[\]\).*</main>

will define the context called 'main' which will match all public static void main methods.

Specifies the custom method contexts to use for filtering specific methods from Clover reports. This is more detailed format compared to methodContexts, which allows to set also code metrics to be matched. Example:

<methodWithMetricsContexts>
    <methodWithMetricsContext>
        <name>simpleGetter</name> <!-- (mandatory) -->
        <regexp>public .* get.*\(\)</regexp> <!-- (mandatory) -->
        <maxComplexity>1</maxComplexity> <!-- at most 1 cycle (optional) -->
        <maxStatements>1</maxStatements> <!-- at most 1 statement (optional) -->
        <maxAggregatedComplexity>2</maxAggregatedComplexity> <!-- no more than 2 cycles including inline classes (optional) -->
        <maxAggregatedStatements>10</maxAggregatedStatements> <!-- no more than 10 statements including inline classes (optional) -->
    </methodWithMetricsContext>
    <!-- can add more methodWithMetricsContext -->
</methodWithMetricsContexts>

will define a context called 'simpleGetter' which matches all public getXyz() methods containing at most one statement; this statement may contain more complex logic (an anonymous inline class) but not bigger than 9 statements.

List of all artifacts for this Clover plugin provided by Maven. This is used internally to get a handle on the Clover JAR artifact.

Note: This is passed by Maven and must not be configured by the user.

The Maven project instance for the executing project.

Note: This is passed by Maven and must not be configured by the user.

Try to protect your build from installing instrumented artifacts into local ~/.m2 cache or deploying them to a binaries repository. If this option is enabled, Clover will fail a build whenever it detects that 'install' or 'deploy' phase is about to be called. It will also fail a build if it detects that an artifact having multiple classifiers (e.g. "-clover-tests.jar"), which are not supported by Maven, is about to be installed under original name (e.g. "-tests.jar").

Please note that this flag may not protect from all possible cases.

If set to true, Clover will add several properties to the build configuration which disable a build failure for following plugins:

• maven-surefire-plugin (maven.test.failure.ignore=true)
• maven-failsafe-plugin (maven.test.failure.ignore=true)
• maven-checkstyle-plugin (checkstyle.failOnViolation=false)
• maven-pmd-plugin (pmd.failOnViolation=false)

Thanks to this, build continues despite test failures or code validation failures and thus it is possible to generate a Clover coverage report for failed tests at the end of the build.

Note: before version 3.1.9 the testFailureIgnore property was set to true for the forked Clover lifecycle ('instrument' goal) for 'test' and 'integration-test' phases. Since 3.1.9 it is no longer set.

By default, Clover Maven Plugin generates the ${java.io.tmpdir}/grover*.jar file during setup, which is next being added as the dependent artifact to the build. As the file has generated, unique name and the jar is not being removed at the end of the build, these files can litter the temporary directory.

In case when there is no Groovy code in the project, this parameter can be set to true in order to disable generation of grover.jar artifact.

If true we'll wait 2*flushInterval to ensure coverage data is flushed to the Clover database before running any query on it.

Note: The only use case where you would want to turn this off is if you're running your tests in a separate JVM. In that case the coverage data will be flushed by default upon the JVM shutdown and there would be no need to wait for the data to be flushed. As we can't control whether users want to fork their tests or not, we're offering this parameter to them.