Workaround for cobertura.ser location

Already fixed in current 2.1 snapshot, added to keep track of the change

Workaround will fail with next release of Cobertura.
A proper mechanism using cobertura.properties file will be appropriate way to accomplish this.

Reopened so that we can track the removal of this hack for the next cobertua release.

> Workaround will fail with next release of Cobertura.

well, actually the workaround is "move the file if found in the wrong location". If the next release of cobertura will accept the correct path for the file through the properties file this should not be a problem: the plugin will not find anything to move and it will be happy to use the correct file. Did I misunderstand anything?

Due to the embedded nature of the cobetura.ser file with cobertura 1.8. (the instrumented classes have the cobertura.ser file location embedded in the class) doing an aggregate or merge (either by action of the user, or internal usage of those bits by cobertura or the plugin) the cobertura.ser data can get out of sync and produce invalid results (usually manifested in 0% or 100% coverages, or missing classes in the report).

Moving the file as part of a single project execution is safe, but once you get into unit + integration tests, or multi-project builds, or reactor builds, or using external tools such as QALabs, you'll encounter issues.

This hack addresses a small set of bugs.
The next cobertura has many overhauls to the configuration. (cobertura.ser file location, and ignores / excludes definitions to name some of the big ones)

This is not the first time this hack has been introduced to cobertura.
It existed before. And was removed for causing problems.

I think I have the same issue. When running the recently released version 2.1 of the cobertura maven plugin, I get lots of these errors:

net.sourceforge.cobertura.reporting.html.HTMLReport - Data file does not contain instrumentation information for the file xxx. Ensure this class was instrumented, and this data file contains the instrumentation information.

This effectively makes this version useless for me. I had to go back to 2.0.

Is there a workaround?

Having the same problem as Aaron Digulla, but it seems like it only happens on our Linux build machine and not on my Windows machine. Strange.

Having the same problems on a windows machine, seems that going back to surefire-plugin 2.1.3 instead of 2.2.0 solve the issue, anyway I stay with cobertura 1.7.

Same problem here. Switch back to 2.0 manually solves the problem:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.0</version>

Same problem here. hence cannot use cobertura 1.8!! please solve this!

Same here. Using version 2.0 worked for me.

Has anyone looked at cobertura 1.9 yet? Does this fix this issue? I'm still using the 2.0 plugin to avoid this.

Same problem here. Linux, mvn 2.0.6. Setting plugin version to 2.0 solves.

Michael: Please try the latest 2.2-SNAPSHOT of this plugin. It uses Cobertura 1.9.

Fixed with cobertura 1.9
By default the cobertura.ser file is now in :
$

/cobertura/cobertura.ser

It can be changed in the plugin config with :

<plugin>
<artifactId>cobertura-maven-plugin</artifactId>
<configuration>
<dataFile>$

/target/test-harness/check/cobertura.ser</dataFile>
</configuration>
</plugin>