We have a Maven multi module project consisting of a parent (HelloWorld) and different children (HelloWorldServices and HelloWorldPresentation) and use Jenkins to build.
The error after running the successful test is
[INFO] --- jacoco-maven-plugin:0.7.6.201602180812:report (default-cli) @ HelloWorldServices ---
[INFO] Skipping JaCoCo execution due to missing execution data file:/var/lib/jenkins/workspace/HelloWorld/HelloWorldServices/target/jacoco.exec
The lines before it says
[INFO] --- jacoco-maven-plugin:0.7.6.201602180812:prepare-agent (default-cli) @ HelloWorldServices ---
[INFO] argLine set to -javaagent:/var/lib/jenkins/.m2/repository/org/jacoco/org.jacoco.agent/0.7.6.201602180812/org.jacoco.agent-0.7.6.201602180812-runtime.jar=destfile=/var/lib/jenkins/workspace/HelloWorld/HelloWorldServices/target/jacoco.exec
This is how I defined the parent pom JaCoCo plugin:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.6.201602180812</version>
<configuration>
<destfile>${project.artifactId}/target/jacoco.exec</destfile>
<datafile>${project.artifactId}/target/jacoco.exec</datafile>
</configuration>
<executions>
<execution>
<id>jacoco-initialize</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>jacoco-site</id>
<phase>package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
In no pom did I explicitly mention surefire. I also tried what you find everywhere to put the argLine in the configuration but all with the same result. The JaCoCo .exec file has never been created, no matter what I do. As for the goals, I use
mvn clean install jacoco:prepare-agent jacoco:report
Since when I omit the jacoco goals, it doesn't even display the INFO message.
You should not invoke the agent after the install phase but before, so instead of invoking:
mvn clean install jacoco:prepare-agent jacoco:report
You should invoke
mvn clean jacoco:prepare-agent install jacoco:report
The main reason is: the agent will not participate to the build lifecycle, the test
phase will already be executed as part of the install
phase, then Maven will execute the agent as per command line invocation, but it will be too late.
You should probably also change the plugin configuration above to:
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.6.201602180812</version>
<executions>
<execution>
<id>jacoco-initialize</id>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>jacoco-site</id>
<phase>package</phase>
<goals>
<goal>report</goal>
</goals>
</execution>
</executions>
</plugin>
Note: I removed the configuration section, because it was actually pointing to default values. Moreover, XML elements are case sensitives here, so your datafile
element was simply ignored, it should have been dataFile
instead. The same applies to destFile
.
The prepare-agent
goal is already using ${project.build.directory}/jacoco.exec
as default destFile
value, the same applied to the dataFile
value for the report
goal. The main reason for this change would be a more flexible and standard build, not relying on artifactId
as project name (the default, but still not mandatory) and using the more generic ${project.build.directory}
property instead to point directly at target
.
Final note: make sure to configure the Jacoco Plugin executions within the build/plugins
section and not build/pluginManagement/plugins
section. The pluginManagement
section is meant for governance and common harmonization of versions or configurations, but it will be ignored if the corresponding plugin would not be declared under build/plugins
.
As per official Maven POM reference
pluginManagement: is an element that is seen along side plugins. Plugin Management contains plugin elements in much the same way, except that rather than configuring plugin information for this particular project build, it is intended to configure project builds that inherit from this one. However, this only configures plugins that are actually referenced within the plugins element in the children. The children have every right to override
pluginManagement
definitions.
(note: bold is mine)