Unable to run JUnit 4 tests successfully when using Jacoco - java-11

We have recently upgraded our project to JDK 11 and have noticed that Surefire no longer generates the .exec file for Jacoco. Casting around for a solution, we modifier our Maven POM file to pick up the arg from Jacoco and give it to Surefire, as shown below:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.8.4</version>
<executions>
<execution>
<id>jacoco-initialize</id>
<goals>
<goal>prepare-agent</goal>
</goals>
<!-- gets the aguament from here -->
<configuration>
<propertyName>surefireArgLine</propertyName>
</configuration>
</execution>
<execution>
<id>post-unit-test</id>
<phase>test</phase>
<goals>
<goal>report</goal>
</goals>
<configuration>
<outputDirectory>./codeCoverage/</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.7</version>
<configuration>
<!-- and uses it here -->
<argLine>
${surefireArgLine}
-Xmx1024m
-javaagent:"${settings.localRepository}"/org/jmockit/jmockit/1.9/jmockit-1.9.jar
--add-reads java.base=java.logging
--add-reads java.xml=java.logging
</argLine>
</configuration>
</plugin>
Now, although the .exec is produced for Jacoco, the unit tests fail with the following:
java.lang.ArrayIndexOutOfBoundsException: Index 110 out of bounds for length 110
      at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
      at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
      at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
      at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
      at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
      at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
We've tried upgarding various parts (JMockit to 1.23, Surefire to 2.22.2), but to no avail: they produce variations on the above.
Has anyone come across a similar situation and have any useful suggestions? It all worked fine under JDK 1.8
Update: and surefireArgLine gets set to
[INFO] --- jacoco-maven-plugin:0.8.3:prepare-agent (coverage-initialize) ---
[INFO] surefireArgLine set to -javaagent:.m2/repository/org/jacoco/org.jacoco.agent/0.8.3/org.jacoco.agent-0.8.3-runtime.jar=destfile=/target/jacoco.exec

And I figured out a solution.
Firstly, as above, add the parameter to allow Jacoco to add an argument to the argLine of Surefire.
Then make sure this is the line after the javaagent parameter for JMockit (otherwise, this blocks the JMockit line and you get an error saying that JMockit requires JDB 6+):
<argLine>
-Xmx1024m
-javaagent:"${settings.localRepository}"/org/jmockit/jmockit/1.9/jmockit-1.9.jar
${surefireArgLine}
--add-reads java.base=java.logging
--add-reads java.xml=java.logging
</argLine>
Finally, make sure that Jacoco is version 0.8.3, as there is a problem with 0.8.4 (called the "condy" problem) See GitHub issue comment

Related

Maven annotation processing with maven-compiler-plugin

I try to compile my code that contains annotations that generate source code. I use the maven-compiler-plugin and build-helper-maven-plugin. My POM is looking like that:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.2</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<generatedSourcesDirectory>${project.build.directory}/generated-sources/apt</generatedSourcesDirectory>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>build-helper-maven-plugin</artifactId>
<version>1.5</version>
<executions>
<execution>
<phase>generate-sources</phase>
<goals>
<goal>add-source</goal>
</goals>
<configuration>
<sources>
<source>${project.build.directory}/generated-sources/apt</source>
</sources>
</configuration>
</execution>
</executions>
</plugin>
When I run mvn compile, ${project.build.directory}/generated-sources/apt is added as a source directory, and the generated sources are generated in the correct directory. But I get compiler errors because of missing references to the generated classes. It's like the generated source directory is not included in the compilation process.
I also try apt-maven-plugin which does not generate anything. And maven-annotation-plugin but it behaves as describe above.
The release 2.0.7-SNAPSHOT of maven-annotation-plugin should solve the problem
fwiw I just downgraded from 3.0 to 2.5.1 and fixed an issue I was seeing with APT processing not being executed after a few runs, using maven so just downgraded one version:
http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.apache.maven.plugins%22%20AND%20a%3A%22maven-compiler-plugin%22
Can you try with the latest version of maven compiler plugin (2.3.2)?
Also build-helper-maven-plugin is not required since it looks like you are using the maven-compiler-plugin itself to generate the sources from the annotation.

How to make jetty-maven-plugin deploy a war that is retrieved from a repository?

I'm setting up an integration test module for a good sized web project. The integration test module is separated from the web project itself, and it has it's own pom.
The idea is to use the maven-soapui-plugin to send requests and verify the response. Setting up the soapui-plugin is no hassle. However, I'm having trouble with figuring out how I can tell the jetty-maven-plugin to deploy a war from a remote repository.
If I have understood correctly, the jetty-maven-plugin has a property called '<webApp>/<webApp>' which lets me specify the war file to deploy. The problem is that the war file is not present in the module itself.
I have heard that I can use the maven assembly plugin to retrieve the war from a repository via the projects artifactId, but I am yet to figure out how I would go about doing so.
Here's a summary of what I want:
Retrieve a specific war from a repository or the like, in example via its artifactId.
Deploy this war to the jetty-maven-plugin (goal deploy-war?)
get maven-soapui-plugin to run tests and report the results back in the integration-test phase.
I am pretty sure I've got step 3 covered, but I am very unsure how to achieve step 1 and 2.
Any help is greatly appreciated
It is maybe possible to use dependency:copy to retrieve the war, unpack it and to get the whole thing working with the maven jetty plugin, but this would be hacky and kinda ugly. A cleaner solution would be to use the Maven Cargo plugin and this is my suggestion. Below, a sample POM showing how to retrieve a WAR artifact using its coordinates and how to deploy it on an embedded Jetty container using Cargo:
<dependencies>
<dependency>
<groupId>war group id</groupId>
<artifactId>war artifact id</artifactId>
<type>war</type>
<version>war version</version>
</dependency>
...
</dependencies>
...
<build>
<plugins>
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<configuration>
<!-- Container configuration -->
<container>
<containerId>jetty6x</containerId>
<type>embedded</type>
</container>
<!-- Configuration to use with the container or the deployer -->
<configuration>
<deployables>
<deployable>
<groupId>war group id</groupId>
<artifactId>war artifact id</artifactId>
<type>war</type>
<properties>
<context>war context</context>
</properties>
</deployable>
</deployables>
</configuration>
<!-- Don't wait, execute the tests after the container is started -->
<wait>false</wait>
</configuration>
<executions>
<execution>
<id>start-container</id>
<phase>pre-integration-test</phase>
<goals>
<goal>start</goal>
</goals>
</execution>
<execution>
<id>stop-container</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
Finally, just bind the soapui plugin on the integration-test phase.
I'm doing the same thing, John, but I took a different approach with the Jetty plugin. I think the end result is the same. I'm developing an integration-test suite to run against several web service WARs. I'm using dependency:copy in the package phase and then a list of <contextHandler/>s configured for maven-jetty-plugin:
<project>
…
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-wars</id>
<phase>package</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/wars-to-be-tested</outputDirectory>
<stripVersion>true</stripVersion>
<artifactItems>
…
<artifactItem>
<groupId>groupId</groupId>
<artifactId>artifactId</artifactId>
<version>version</version>
<type>war</type>
</artifactItem>
…
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.1.3.v20100526</version>
<configuration>
…
<contextHandlers>
…
<contextHandler implementation="org.mortbay.jetty.plugin.JettyWebAppContext">
<war>${project.build.directory}/wars-to-be-tested/artifactId.war</war>
<contextPath>/context</contextPath>
</contextHandler>
</contextHandlers>
</configuration>
<executions>
<execution>
<id>start-jetty</id>
<phase>pre-integration-test</phase>
<goals>
<goal>stop</goal>
<goal>run</goal>
</goals>
<configuration>
<scanIntervalSeconds>0</scanIntervalSeconds>
<daemon>true</daemon>
</configuration>
</execution>
<execution>
<id>stop-jetty</id>
<phase>post-integration-test</phase>
<goals>
<goal>stop</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</project>
I would prefer to declare the various wars as dependencies and then use dependency:copy-dependencies to set up the wars-to-be-tested directory; this would allow the Maven reactor to figure out that it needs to build my integration-test module after the wars it'll be testing. The problem I ran into was that the Jetty plugin thought that I wanted to "overlay" all of the wars that were listed as dependencies (a concept that I'd never even heard of until I saw it happen); I don't know if allowing that to happen would have hurt anything, but I didn't like it, so I went with the dependency:copy method.
This is just an alternative to using Cargo. I'll be looking into that myself, but I just wanted to provide another way of doing it.

Running integration tests with Cobertura Maven plugin

I am having trouble getting the Cobertura plugin to run integration tests in Maven. The closest answer to this question I have found is http://jira.codehaus.org/browse/MCOBERTURA-86. However, the issue remains an open bug. I tried the configuration suggested by Stevo on 03/Apr/09, it didn't work.
My POM
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.3-SNAPSHOT</version>
<reportSets>
<reportSet>
<reports>
<report>cobertura-integration</report>
</reports>
</reportSet>
</reportSets>
</plugin>
</plugins>
</reporting>
which is by the way exactly the same as the configuration fragment provided by Stevo.
From my opinion, the cobertura maven plugin has two big disadvantages. It has no report only goal, all unit tests will run beside surefire again. It creates the code coverage for unit tests only .
I am using the JaCoCo maven plugin now. JaCoCo reuses the surefire and/or failsafe reports to create a code coverage from unit and/or integration test. Furthermore JaCoCo has a good Jenkins integration. Here is an example where JaCoCo uses surefire unit tests and failsafe integration tests.
<build>
<plugins>
<!-- Unit tests -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.16</version>
</plugin>
<!-- Integration tests -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.16</version>
<executions>
<execution>
<phase>integration-test</phase>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
<!--
The JaCoCo plugin generates a report about the test coverage. In contrast to the cobertura plugin
JaCoCo can be configured to generate code coverage for integration tests. Another advantage of JaCoCo
is that it reports only, cobertura executes all unit tests again (beside the surefire plugin).
-->
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.6.4.201312101107</version>
<executions>
<execution>
<id>jacoco-prepare-agent</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>jacoco-prepare-agent-integration</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
</execution>
<execution>
<id>jacoco-report</id>
<goals>
<goal>report</goal>
</goals>
</execution>
<execution>
<id>jacoco-integration</id>
<goals>
<goal>report-integration</goal>
</goals>
</execution>
<execution>
<id>jacoco-check</id>
<goals>
<goal>check</goal>
</goals>
<configuration>
<rules />
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
Try to configure a execution phase for that plugin like
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<formats>
<format>xml</format>
</formats>
</configuration>
<executions>
<execution>
<id>cobertura-check</id>
<phase>verify</phase>
<goals>
<goal>cobertura</goal>
</goals>
</execution>
</executions>
</plugin>
That way it works like a charm for me.
After some research found a working config listed from http://jira.codehaus.org/browse/MCOBERTURA-86
Make sure to invoke this with
mvn clean deploy -PbuildWithIntegrationTestCoverage
<profile>
<!-- Build with IntegrationTestcoverage => instrument classes with cobertura before integrationtests starts. -->
<id>buildWithIntegrationTestCoverage</id>
<activation>
<property>
<name>buildWithIntegrationTestCoverage</name>
<value>true</value>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.5.2</version>
<executions>
<execution>
<id>instrument-classes</id>
<phase>package</phase>
<goals>
<goal>instrument</goal>
</goals>
</execution>
</executions>
</plugin>
<!-- Add cobertura as dependency to the jetty-plugin (required for instrumented classes) -->
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
<dependencies>
<dependency>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.5.2</version>
<type>jar</type>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
For anyone stumbling on this question through Google - cobertura-maven-plugin started supporting integration tests in version 2.7, which was published in 2015.
Quoting their website:
Up to version 2.6 there were only one report available: cobertura,
which gave you a coverage report for your unit tests. Since there was
only one, you didn't have to configure it in any way.
Starting with version 2.7 a new report was added:
cobertura-integration-test, which gives you a coverage report for your
integration tests. [..]
Both reports are enabled by default. If you want the old behaviour
with only a coverage report for your unit tests, you need to configure
the plugin ...
If you, like I did, run cobertura report using mvn cobertura:cobertura, you'll need to do mvn cobertura:cobertura-integration-test to get integration tests as well. You can check the details from its manual page.
I found that using the maven-antrun-plugin for multi-module projects including integration and UI tests is the best solution. I used this post to get the Ant goals down and went from there. We now have code coverage reports per module and merged one containing coverage from all tests.
I got the integration tests working with Maven 3.0.3 and cobertura-maven-plugin 2.5.1 by configuring the maven-failsafe-plugin to run during the test phase:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.12</version>
<executions>
<execution>
<phase>test</phase>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>

How to run individual test in the integration-test target in maven

We have a hundreds of tests defined for our integration-test phase lifecycle in maven, and they take a long time to finish.
What I want to do is run just one test in the integration-test. I tried doing :
mvn -Dtest=<my-test> integration-test
but that does not work. The -Dtest runs only the tests in the unit test goal, not the integration-test phase. I tried the -Dintegration-test=<my-test> instead, and that was ignored.
Is there a way to do that ?
My configuration is:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>surefire-it</id>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<excludes>
<exclude>none</exclude>
</excludes>
<includes>
<include>**/api/**</include>
</includes>
.....
If you're using the Maven failsafe plugin, you can run a single integration test by setting the it.test property to your fully qualified test class name:
mvn -D it.test=your.TestCase verify
See the failsafe plugin docs for more info.
The Failsafe documentation would have you specify the test like so:
mvn -Dit.test=BrokenIT verify
However, -Dit.test does not appear to work any longer. Rather, the same parameter used to specify a Surefire test will apparently work for Failsafe as well. For example:
mvn -Dtest=WorksIT verify
I've filed a bug (EDIT: which was closed as "Cannot Reproduce" in 2.12) to correct the documentation.
just add -DfailIfNoTests=false works for me with testNG. Something like this:
mvn integration-test -Dtest=aITest -DfailIfNoTests=false
I struggled through this, and I created an additional profile to use when I wanted to run just one integration test. I hope that I've successfully extracted just the right part here:
<profile>
<id>integrationTestSingle</id>
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>surefire-it</id>
<phase>integration-test</phase>
<goals>
<goal>test</goal>
</goals>
<configuration>
<includes>
<include>**/integration/**/${test}.java</include>
</includes>
<skipTests>false</skipTests>
</configuration>
</execution>
</executions>
<configuration>
<argLine>-Xms256M -Xmx768M -XX:MaxPermSize=256M</argLine>
</configuration>
</plugin>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<id>default-test</id>
<configuration>
<skipTests>true</skipTests>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
Now, I call maven with the integrationTestSingle profile and with -DfailIfNoTests=false -Dtest=NameOfTest, and it doesn't run any of the regular tests during the regular "test" phase, and runs just the NameOfTest test during the integration-test phase.
I'm not sure about JUnit, but for TestNG the strategy would be to define a suite XML file with only the one test, and then in your POM configure the surefire plugin to only run that. In your POM, you would have something like this (disclaimer, this is untested):
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<executions>
<execution>
<phase>integration-test</phase>
<configuration>
<suiteXmlFiles>
<suiteXmlFile>single-test.xml</suiteXmlFile>
</suiteXmlFiles>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
To configure the suite file, see http://testng.org/doc/documentation-main.html
Just ran into this myself. Something like this worked well for me:
mvn -Pintegration-test -Dtest=<my-test>
The trick was to ensure that the test-group was mentioned before the -Dtest portion.
I am using:
Apache Maven 3.6.3
openjdk version "11.0.2" 2019-01-15
<groupId>org.codehaus.mojo</groupId>
<artifactId>failsafe-maven-plugin</artifactId>
<version>2.4.3-alpha-1</version>
This command worked for me:
mvn failsafe:integration-test -Dsurefire.skip=true -DskipIntegrationTests=false -DskipTests=false -Dtest=com.myxyz.func.ITestGate
Was actually simpler that the answers above by going back to basics with the actual documentation.
Running Junit 5 integration tests:
openjdk version "11.0.11" 2021-04-20
Apache Maven 3.6.3
In the main build just drop in documented failsafe config:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>3.0.0-M5</version>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
Then you can run only a specific integration test with:
mvn -Dtest=\*cs1_\* verify
Note that this version will run your tests in the target folder and if you need to load any external files that are something like src\test\resources\x.y then they are copied to target\test-classes\x.y
This works for me, when I gonna run only one test method in integration test
mvn clean -Dit.test=some.package.SomeTestClass#testMethodName integration-test

Maven2 Multiproject Cobertura Reporting Problems During mvn site Build

We've got a multiproject we're trying to run Cobertura test coverage reports on as part of our mvn site build. I can get Cobertura to run on the child projects, but it erroneously reports 0% coverage, even though the reports still highlight the lines of code that were hit by the unit tests.
We are using mvn 2.0.8. I have tried running mvn clean site, mvn clean site:stage and mvn clean package site. I know the tests are running, they show up in the surefire reports (both the txt/xml and site reports). Am I missing something in the configuration? Does Cobertura not work right with multiprojects?
This is in the parent .pom:
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<inherited>true</inherited>
<executions>
<execution>
<id>clean</id>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<inherited>true</inherited>
</plugin>
</plugins>
</reporting>
I've tried running it with and without the following in the child .poms:
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
</plugin>
</plugins>
</reporting>
I get this in the output of the build:
...
[INFO] [cobertura:instrument]
[INFO] Cobertura 1.9 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
Instrumenting 3 files to C:\workspaces\sandbox\CommonJsf\target\generated-classes\cobertura
Cobertura: Saved information on 3 classes.
Instrument time: 186ms
[INFO] Instrumentation was successful.
...
[INFO] Generating "Cobertura Test Coverage" report.
[INFO] Cobertura 1.9 - GNU GPL License (NO WARRANTY) - See COPYRIGHT file
Cobertura: Loaded information on 3 classes.
Report time: 481ms
[INFO] Cobertura Report generation was successful.
And the report looks like this:
I suspect that you're missing an execution of cobertura plugin during the compile phase so that the code only gets instrumented by the reporting plugins, in the site lifecycle, after the tests were run. So the test runs aren't picked up because they run on non-instrumented code. Analyze your build logs more carefully - if I'm right, you'll notice that surefire tests are executed before cobertura:instrument.
My configuration is similar to yours, but in addition to specifying the clean exectution in pluginManagement (like you), I specify the cobertura plugin explicitly in build plugins section:
<build>
...
<plugins>
...
<plugin>
<inherited>true</inherited>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>${cobertura.plugin.version}</version>
</plugin>
</plugins>
</build>
My configuration sorta works, and all Cobertura stuff is in the global organization-wide pom, which all projects use as a parent.
This way projects don't specify anything Cobertura-related in their pom.xml's, but they still generate coverage reports.
I haven't been succesful at getting Cobertura to combine reporting from multi-projects. This has been a problem in general with multi-project reporting.
We have been evaluating sonar as a solution for our metrics reporting. It seems to do a great job of providing summary metrics across projects, including multi-proijects.
The solution implemented by me is somewhat manual, but works. It consists of several steps of one is a step to combine the several .ser files that are generated by Cobertura. This can be done by using the cobertura-merge commandline tool inside a maven task.
According to the output you show is that the files are not actually instrumented, it tells that only 3 files are instrumented.
#Marco is right, it is not possible to achieve this normally through maven only as the maven cobertura plugin is missing a merge goal.
You can achieve it through a mix of maven and ant goals : http://thomassundberg.wordpress.com/2012/02/18/test-coverage-in-a-multi-module-maven-project/
Nevertheless, in the case you have one single project undertest, there is no need to merge. You can, in the test project, copy the .ser file and the instrumented classes from the project under test :
//in test project
<plugin>
<groupId>com.github.goldin</groupId>
<artifactId>copy-maven-plugin</artifactId>
<version>0.2.5</version>
<executions>
<execution>
<id>copy-cobertura-data-from-project-under-test</id>
<phase>compile</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<resources>
<resource>
<directory>${project.basedir}/../<project-under-test>/target/cobertura</directory>
<targetPath>${project.basedir}/target/cobertura</targetPath>
<includes>
<include>*.ser</include>
</includes>
</resource>
<resource>
<directory>${project.basedir}/../<project-under-test>/target/generated-classes/cobertura/</directory>
<targetPath>${project.basedir}/target/generated-classes/cobertura</targetPath>
<preservePath>true</preservePath>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin>
//in parent project
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<configuration>
<format>xml</format>
<aggregate>true</aggregate>
</configuration>
<executions>
<execution>
<goals>
<goal>clean</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>${cobertura.version}</version>
</plugin>
</plugins>
</reporting>