I have a some 'custom code' that runs during the maven project build. I would like to use cobertura's line coverage feature to generate report of the executed lines of my 'custom code' for a build.
What I have achieved so far:
- I am using the maven cobertura plugin to generate the report.
- The execution of 'custom code' is bound to the test phase of maven build.
- The maven goal cobertura:cobertura runs cobertura:instrumentation first and then in the test phase my 'custom code' is executed.
The unexpected behavior:
Although, I expected the cobertura reports to show line coverage, the line coverage reports shows just 0.
Further investigating the issue I found that the cobertura:instrumentation takes place in a separate vm. Following a snapshot of the processes that are listed by 'ps' command.
6647 ? S 0:00 /bin/sh -c /home/user/softwares/JDK/jdk1.7.0_79/jre/bin/java -Dlog4j.configuration=file:/tmp/log4j628942363594701372config.properties -Xmx64m net.sourceforge.cobertura.instrument.InstrumentMain --commandsfile /tmp/cobertura.5724213382380101768.cmdline
6649 ? D 0:00 /bin/sh -c /home/user/softwares/JDK/jdk1.7.0_79/jre/bin/java -Dlog4j.configuration=file:/tmp/log4j628942363594701372config.properties -Xmx64m net.sourceforge.cobertura.instrument.InstrumentMain --commandsfile /tmp/cobertura.5724213382380101768.cmdline
Attempts at solving this:
- In order to resolve this, I've tried to find how jmockit achieves the same. Haven't really been able to figure that out yet.
I have also tried attaching the execution code to the already running VM.
com.sun.tools.attach.VirtualMachine.attach(arg0);
Can somebody please help me out here.
Update - 23th October 2015
As per an excerpt from Cobertura Github Wiki,
java -cp C:\cobertura\lib\cobertura.jar;C:\MyProject\build\instrumented;C:\MyProject\build\classes;C:\MyProject\build\test-classes -Dnet.sourceforge.cobertura.datafile=C:\MyProject\build\cobertura.ser ASimpleTestCase
This should run the tests with the cobertura's instrumented code. I tried this with an extra -javaagent:agent.jar. This doesn't seem to work either.
