openclover / clover Goto Github PK

Currently in majority the instrumentation, test with clover and report task are provided as a plain Gradle tasks. Make them TaskTypes to allow users to modify the configuration.

Currently JDK 1.6 is required in order to build Clover because of APT annotation processor.

Let's move the code to javax.annotation.processor to make Clover compile-able on JDK 1.8+

Add ability to include exclude file patterns from instrumentation

I am running mvn build on a multimodule project with clover plugin.

The command ran is mvn clover:setup test clover:aggregate clover:clover No goal in the pom defined.

The pluging fails with

[ERROR] Failed to execute goal org.openclover:clover-maven-plugin:4.2.0:aggregate (default-cli) on project parent: Execution default-cli of goal org.openclover:clover-maven-plugin:4.2.0:aggregate failed: String index out of range: -25 -> [Help 1]

Note that it runs in docker. against the image maven:3-jdk-8

After looking at the plugin source code i found the problem to originate in com.atlassian.maven.plugin.clover.CloverAggregateMojo

private List<String> getChildrenCloverDatabases() {
    // Ideally we'd need to find out where each module stores its Clover
    // database. However that's not
    // currently possible in m2 (see
    // http://jira.codehaus.org/browse/MNG-2180). Thus we'll assume for now
    // that all modules use the cloverDatabase configuration from the top
    // level module.

    // Find out the location of the clover DB relative to the root module.
    // Note: This is a pretty buggy algorithm and we really need a proper
    // solution (see MNG-2180)
    final String resolvedCloverDb = resolveCloverDatabase();
    final String projectBaseDir = getProject().getBasedir().getPath();
    getLog().debug("Calculating relative database path of '" + resolvedCloverDb
            + "' against the project base directory '" + projectBaseDir + "'");
    final String relativeCloverDatabasePath = resolvedCloverDb.substring(projectBaseDir.length());
More specifically when i run it with debug info

[DEBUG] Calculating relative database path of '/var/folders/cc/l8sxh9z54cq8t1fxqx928g2w0000gn/T//clover.db' against the project base directory '/Users/NyName/code/company/myproject/MySecret-service/builds/0/project-0'```

Project base dir has length 72 ResolvedCloverDb dir has length 59 Which then of course results in the index out of range exception on substring.

(The log message says relative but the variable resolvedCloverDB is not relative. Deprecated log message?)

The value of ResolvedCloverDB running in a docker image obviously goes wrong.

I solved it by configuring the plugin that it uses one single clover db.

              ```<plugin>
                    <groupId>org.openclover</groupId>
                    <artifactId>clover-maven-plugin</artifactId>
                    <version>${clover-maven-plugin.version}</version>
                    <configuration>
                        <singleCloverDatabase>true</singleCloverDatabase>
                        <debug>true</debug>
                    </configuration>
                </plugin>```

But if found the error very cryptic and hard to find. Took me some debugging.

Summarize what's happening:

4.2.0 (and 4.2.1?) are out
documentation site
new sbt plugin
new gradle plugin in progress
clover on tricity hackatons

Links on this page point to confluence.atlassian.com and we have our documentation on openclover.org now

Use Maven 3.0.4 as minimum required version. Bump dependencies.

Replace javadoc tags by annotations in mojos.

Get rid of deprecated classes (e.g. ArtifactFactory).

Solve a blocker bug - the localRepository field is not being injected after bumping to Maven 3 - it makes impossible to use "clover:instrument" goal.

Drop support for Maven 2 as it's reached end of life:

http://maven.apache.org/maven-2.x-eol.html

TestWithClover task must be aware of instrumented test sources and modify test classpath accordingly to invoke tests against instrumented sources.

Ensure that the OpenClover fork will not violate any trademark rights of Atlassian. Remove any references to Atlassian (R), Atlassian Clover (R), Atlassian Charlie logo etc where applicable. Keep (c) Atlassian where applicable. Update licensing information that it's based on the Apache License 2.0. Update URLs used in application.

A common use case for method contexts is filtering out accessors. In fact, A pre-defined context for that already exists. However, this context matches more methods than just trivial accessors (accessors with lazy initialisation and many others), since it just checks the method signature. A project may want non-trivial accessors test-covered, while filtering out the trivial ones.

This use case can be implemented by using maxComplexity / maxStatements and their aggregated version in ant, but not by maven plugin configuration itself.

There is an improvement request in Altassian's Clover Jira related to this: https://jira.atlassian.com/browse/CLOV-1173

However, I'd like to suggest for your consideration a slightly different approach that might be easier to implement: by using attributes for the new properties, the current implementation that takes the tag itself as name of the context can remain as is, and the backwards compatibility is preserved. eg:

In the Clover HTML output, Clover marks JUnit tests that use the JUnit @rule ExpectedException to check for customized exceptions as failures, even though the test actually passes. For example:

public void testGetSubscriptionScopeDetailNoCsScope() {
    expectedException.expect(YyyyException.class);
    expectedException.expect(ErrorMatcher.method(xxx));

    object.method();
}```

Summary: Clover always selects a JUnit test suite, i.e., @RunWith(Suite.class), even if (test) classes are not changed.

Steps to Reproduce: Unzip the attached file. Run the bash script ./s provided in this directory. This script consecutively runs the same test suite twice with clover.

Expected Results: p.RegressionTest runs in the first execution and does not run in the second execution.

Actual Results: p.RegressionTest runs in both the first and the second execution.

Create a first "official" release of the plugin for Gradle.

HTR
Create multi-project project when one of the sub-projects has no Groovy/Java sources, like EAR or WAR project.
Run Clover for Gradle and try to generate report
Expected results
Report is properly generated for multi-project and projects without sources are simply ignored.

Actual results ###
FileNotFoundException is thrown on cloverReport task when there's no clover.db file. And there's no such since there weren't any sources to instrument. It shouldn't be always important to have a clover.db in every module.

Make links to documentation in OpenClover's source code:

Core, Ant, Maven, Eclipse, IDEA
Put links to OpenClover documentation on other sites:

Jenkins, Hudson, Grails plugins

As a part of an effort to integrate openclover into our maven project, we are running into this weird issue were if we included the maven plugin as a part of the build, we get the error below.

$ mvn clean install [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building openclover.maven 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ Downloading: https://repo.maven.apache.org/maven2/org/openclover/clover/4.2.1/clover-4.2.1.pom Downloaded: https://repo.maven.apache.org/maven2/org/openclover/clover/4.2.1/clover-4.2.1.pom (0 B at 0 B/s) Downloading: https://repo.maven.apache.org/maven2/org/openclover/clover/4.2.1/clover-4.2.1.jar Downloaded: https://repo.maven.apache.org/maven2/org/openclover/clover/4.2.1/clover-4.2.1.jar (0 B at 0 B/s) [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.983 s [INFO] Finished at: 2018-01-23T13:50:11-08:00 [INFO] Final Memory: 14M/309M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to parse plugin descriptor for org.openclover:clover:4.2.1 (/Users/sreevatsaks/.m2/repository/org/openclover/clover/4.2.1/clover-4.2.1.jar): No plugin descriptor found at META-INF/maven/plugin.xml -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginDescriptorParsingException
But, it does work when the specific target is run

$ mvn clover:clover [INFO] Scanning for projects... [WARNING] Failed to retrieve plugin descriptor for org.openclover:clover:4.2.1: Failed to parse plugin descriptor for org.openclover:clover:4.2.1 (/Users/ssreeraman/.m2/repository/org/openclover/clover/4.2.1/clover-4.2.1.jar): No plugin descriptor found at META-INF/maven/plugin.xml [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building openclover.maven 1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [WARNING] Failed to retrieve plugin descriptor for org.openclover:clover:4.2.1: Failed to parse plugin descriptor for org.openclover:clover:4.2.1 (/Users/ssreeraman/.m2/repository/org/openclover/clover/4.2.1/clover-4.2.1.jar): No plugin descriptor found at META-INF/maven/plugin.xml [INFO] [INFO] --- clover-maven-plugin:4.2.0:clover (default-cli) @ openclover.maven ---] [WARNING] No Clover database found, skipping report generation [INFO] No report being generated for this module. [INFO] No 'maven.clover.licenseLocation' configured. Using default license. [INFO] Using /default-clover-report descriptor. [INFO] Using Clover report descriptor: /var/folders/km/2hj1cy6530vbj7syhmbqpyxr_h_245/T/mvn7781235465199595890resource [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 2.716 s [INFO] Finished at: 2018-01-23T13:55:07-08:00 [INFO] Final Memory: 21M/325M [INFO] ------------------------------------------------------------------------
(Please disregard the database not found. That is expected.)

As you can see it becomes a warning.

Can you please take a look at the plugin descriptor issue, it is becoming somewhat of a blocker to start using.

I have a created a test repository here https://bitbucket.org/sreevatsaks/openclover-maven.

Take exports of Confluence pages from atlassian-docs.bitbucket.io and copy them to openclover.org.

Update this documentation for OpenClover 4.2 release content:

merge user manual and knowledge base spaces into one /done/
apply CSS styling /done/
add navigation header /done/
add copyright footer /done/
replace com.atlassian.* artifactId by openclover ones, update code snippets /done/
use 'OpenClover 4.2' title instead of 'Clover 4.1' /done/
hook documentation under the openclover.org/documentation, redesign the main page /done/
remove obsolete attachments /done/
remove obsolete pages /done/

add hamcrest from tutorial/lib folder

otherwise test execution fails with

Exception in thread "main" java.lang.NoClassDefFoundError: org/hamcrest/SelfDescribing at java.lang.ClassLoader.defineClass1(Native Method)

I have a multimodule maven project composed by ModuleA and ModuleB. ModuleA is a dependency required by ModuleB.

ModuleA contains this class:

`public class ClassA{

private Long attribute;

public ClassA() {
    super();
}

public ClassA(Long value) {
    super();
    this.attribute = value;
}

}`

ModuleB contains this class:

`public class ClassB{

public void methodB() {
    ...
    ClassA classA = new ClassA(1L);
    ...
}

}`

When i generate clover report using maven like that:

mvn clover:instrument clover:aggregate clover:clover
i have this compilation error while compiling ModuleB

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile (default-compile) on project xxx: Compilation failure [ERROR] constructor ClassA in class ClassA cannot be applied to given types; [ERROR] required: no arguments [ERROR] found: long [ERROR] reason: actual and formal argument lists differ in length

the error disappear if I use the default constructor. It seems a problem due to code instrumentation as the code builds correctly when generating the deploy package.

[exec] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-dependency-plugin:2.10:get (default-cli) on project clover-base-pom: Couldn't download artifact: Missing: [exec] [ERROR] ---------- [exec] [ERROR] 1) net.sf.jtreemap:ktreemap:jar:1.1.0-atlassian-01 *

Changes in pom.xml and build.xml files:

Use org.openclover for groupId instead of com.atlassian.clover and com.atlassian.maven.plugins.
Remove central-pom parent.
Use new update site for Eclipse: openclover.org/update
Use new downloads site for Ant, Eclipse, IDEA: openclover.org/downloads
Use new Maven repository for Core, Maven, AspectJ: oss.sonatype.org

Currently when projects redefines the build dir to e.g. target Clover ignores that configuration and instruments code to build directory

I have code annotated for Checker Framework:

protected final ListOrderedMap<@Interned String, Table> tables = ListOrderedMap.listOrderedMap(new ConcurrentHashMap<>());

The type annotation causes Clover instrumentation to throw the exception below. Removing the type annotation immediately fixes the problem. Surrounding it (e.g. /* CLOVER:OFF / @Interned / CLOVER:ON */) has no effect.

com.atlassian.clover.api.CloverException: myfile.java:87:5:unexpected token: protected
at com.atlassian.clover.instr.java.Instrumenter.instrument(Instrumenter.java:159)
at com.atlassian.clover.CloverInstr.execute(CloverInstr.java:76)
at com.atlassian.clover.CloverInstr.mainImpl(CloverInstr.java:54)
at com.atlassian.maven.plugin.clover.internal.instrumentation.AbstractInstrumenter.instrumentSources(AbstractInstrumenter.java:197)
at com.atlassian.maven.plugin.clover.internal.instrumentation.AbstractInstrumenter.instrument(AbstractInstrumenter.java:72)
at com.atlassian.maven.plugin.clover.CloverInstrumentInternalMojo.execute(CloverInstrumentInternalMojo.java:289)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.MojoExecutor.executeForkedExecutions(MojoExecutor.java:353)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:198)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:993)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:345)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:191)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: line 87:5: unexpected token: protected
at com.atlassian.clover.instr.java.JavaRecognizer.field(JavaRecognizer.java:2440)
at com.atlassian.clover.instr.java.JavaRecognizer.classBlock(JavaRecognizer.java:1857)
at com.atlassian.clover.instr.java.JavaRecognizer.classDefinition(JavaRecognizer.java:865)
at com.atlassian.clover.instr.java.JavaRecognizer.typeDefinition2(JavaRecognizer.java:795)
at com.atlassian.clover.instr.java.JavaRecognizer.typeDefinition(JavaRecognizer.java:648)
at com.atlassian.clover.instr.java.JavaRecognizer.compilationUnit(JavaRecognizer.java:566)
at com.atlassian.clover.instr.java.Instrumenter.instrument(Instrumenter.java:211)
at com.atlassian.clover.instr.java.Instrumenter.instrument(Instrumenter.java:124)
Why it references protected instead of the annotation itself I have no idea, but I have attempted this on several different annotated files and it always spits out the first word on whatever line has the type annotation.

https://en.wikipedia.org/wiki/Java_Code_Coverage_Tools

and link to http://openclover.org/doc/manual/4.2.0/general--comparison-of-code-coverage-tools.html

Clover Gradle must have ability to instrument test sources to enable gathering of per-test coverage

Due to version bump of plugins used to build clover-maven-plugin (e.g. maven-plugin-plugin, plexus-compiler), the 4.2.0 release is not compatible with Maven 2. It throws 'InternalPluginError' exception (reported by users). Investigate it and downgrade plugin versions.

Thanks for making this happen. I'm excited at the prospect of using this.

When using the gradle plugin (commit d203d2e824fc) in a groovy project, the plugin reports this:

:grooves-groovy:cloverInstrument FAILED

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':grooves-groovy:cloverInstrument'.

Clover sourceSet can't have more than 1 src directory

Grzegorz Lewandowski:

Thanks for raising this, I was aware of this limitation but I've never raised an issue to cover this. However, the limitation rather apply to Java code since Gradle plugin at its current state is not able to handle Groovy code. It's because Groovy instrumentation happens during compilation time via AST transformations. Adding Groovy support is on our list but firstly we need to solve blockers in regards of OpenClover for Maven and Gradle -> Java instrumentation.

The current configuration requires to manually update the pom.xml/goals.txt/invoker.property files for the integration tests and some manual scripts to clean up etc. The better way would be to let clone the it's by the maven-invoker-plugin and let filter the version of the project to make sure to really run the integration-test on the currently developed version of the maven plugin. This makes the handling and maintenance of the integration tests simpler.

Summary: If a class is moved from one directory to another (without changing the package name), and the class is changed, Clover does not detect the modification. This is a safety issue (i.e., a bug may be missed).

Steps to Reproduce: Run the bash script ./s provided in this directory. This script (1) runs test with clover, (2) moves class C2 from src/test to src/main, (3) changes the return value of method f under test, and (4) runs the same test with Clover again.

Expected Results: p.C1Test fails in the second execution.

Actual Results: p.C1Test passes in the second execution.

Explanation: Clover keeps the original instrumented class in target/clover/src-instrumented/ although it should be deleted.

HTR
Have project with 2 modules
In Module 1 have a class, ClassA
In Module 2 have a class ClassB and ClassB which uses ```ClassA````
Write test which executes ClassB and effectively ClassA methods
Generate Clover report
Expected result
Clover correctly determine references between classes in different modules

Actual result
Clover report indicates CloverA as not covered by any test.

This page describes "instrument" goal. Add section about "setup". Provide quick integration hints

Currently the maven-surefire-plugin configures explicit *Test.java but that are already the defaults so the given configuration can be omitted.

The configuration of the encoding can be simplified. Also the .hgignore should be enhanced to ignore target directory.

I'm experiencing an issue with 1 unit test in my code base.

An exception has occurred in the compiler (1.8.0_152). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program and the following diagnostic in your report. Thank you.

java.lang.AssertionError at com.sun.tools.javac.util.Assert.error(Assert.java:126) at com.sun.tools.javac.util.Assert.check(Assert.java:45) at com.sun.tools.javac.code.SymbolMetadata.setDeclarationAttributesWithCompletion(SymbolMetadata.java:161) at com.sun.tools.javac.code.Symbol.setDeclarationAttributesWithCompletion(Symbol.java:215) at com.sun.tools.javac.comp.MemberEnter.actualEnterAnnotations(MemberEnter.java:952) at com.sun.tools.javac.comp.MemberEnter.access$600(MemberEnter.java:64) at com.sun.tools.javac.comp.MemberEnter$5.run(MemberEnter.java:876) at com.sun.tools.javac.comp.Annotate.flush(Annotate.java:143) at com.sun.tools.javac.comp.Annotate.enterDone(Annotate.java:129) at com.sun.tools.javac.comp.Enter.complete(Enter.java:512) at com.sun.tools.javac.comp.Enter.main(Enter.java:471) at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:982) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857) at com.sun.tools.javac.main.Main.compile(Main.java:523) at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129) at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138) at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:126) at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:174) at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1075) at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:168)

I'm running the following:

MacOS High Sierra
JDK 8 Update 152
Maven 3.5.2
Openclover 4.2.1
I have been running the plugin like this with:

mvn clover:clean clover:instrument clover:aggregate clover:clover

and that runs fine.

The MavenIntegrator calls "com.atlassian.clover:clover-maven-plugin" instead of "org.openclover:clover-maven-plugin". Correct the groupId.

The AntIntegrator just adds -lib and -listener options, so it works fine with OpenClover's clover.jar. However it is impossible to distinguish between Atlassian and OpenClover when both JARs are available in the class path. Fix it by renaming the ClassPathUtils (used by the AntIntegrator).

Change package name of both AntIntegrator and MavenIntegrator to make possible concurrent usage of Atlassian Clover and OpenClover by Jenkins, Hudson and Bamboo.

README in source repositories, any readme in product etc. Point to openclover.org where applicable.

Issues: #38, #40, #42, #45, #46, #48

Clover quite often fails when compiles code having @CompileStatic annotation.

As this annotation is widely used, this is a critical problem for Groovy.

Details here https://jira.atlassian.com/browse/CLOV-1863

Some people prefer to use RSS instead of a newsletter.

In the case a user doesn't need history at all (which seems to be the most common case because generateHistorical is false by default), the CloverReportMojo always generates an unjustified warning:

[WARNING] Clover historical directory [...] does not exist, skipping Clover historical report generation ([...])

I suppose that it was the point of the generateHistorical parameter in CloverReportMojo but it does change the warning behavior because this parameter doesn't seem to be used.

Currently Clover for Gradle invokes: CloverInstr#main which writes everything to standard output. It's hard to be read for a end-user.

We should use Gradle logger + potentially fail a build if something was broken.

Original report: https://bitbucket.org/openclover/clover/issues/16

Release basic set of integrations: Core + Ant + Eclipse + IDEA + Maven.

There are no changes in other integrations, so we don't have to release them.

Maven 3.5.0+ introduced significant changes in artifact resolution and handling in a project reactor. Test if current version of clover-maven-plugin works with Maven 3.5.0 and above and update 'supported platforms' page accordingly.

mvn 3.5.0 + jdk 1.8 - integration tests ok
mvn 3.5.0 + jdk 1.7 - integration tests ok

It seems that the plugin works with Maven 3.5. At least our integration tests are green (and they test both setup and integration goals, also in a multi-module project).

HTR
Install Ant 1.10.0 or newer
Run
ant global.clean
Expected results
Ant executes submodules properly

Actual result
It fails with given message:

global.clean:

BUILD FAILED
/Users/glewandowski/opensource/clover/build.xml:53: The following error occurred while executing this line:
/Users/glewandowski/opensource/clover/build.xml:24: The following error occurred while executing this line:
/Users/glewandowski/opensource/clover/build.xml:15: you can only specify one of the dir and file attributes
Workaround
Use Ant 1.9.4+ but lower than 1.10

HTR
Setup simple Maven project with Clover
Make sure generateHistorical is set to false
Generate coverage files, execute clover:clover
Expected behaviors
No historical report is generated

Actual behavior
Is there's no coverage data in historicalDir Clover will produce warning message:

Clover historical directory [/tmp/clover] does not exist, skipping Clover historical report generation

If i have a clover report in HTML (generated by the maven plugin) I can navigate to the application code (clover/pkg-summary.html) and having several columns available which can be sorted by clicking on the column header like package, files etc. but on the column TOTAL coverage(right columns) this does not work. For me it looks like an issue...cause if I'm over the column with the mouse it shows an arrow down...

After taking a deeper look into the integration tests I'm asking what is the intention of the fork-maven-plugin test? It does not have a relationship to the clover-maven-plugin nor does it use it? WDYT ? I would suggest to remove this test.