SonarQube "coverage is set to 0% as no JaCoCo execution data has been dumped"
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In a multi-project based maven build with relatively larger unit tests, one would be familiar with the requirements of memory parameters such as Xmx, XX:MaxPermSize, etc passed with MAVEN_OPTS or within surefire plugin. | |
This also comes to help with issues of Java Code Coverage (jacoco) when performing analysis in SonarQube. Recently during analysis with sonarqube and jacoco as coverage plugin, we have been observing that our CI builds pass unit test but certain sub-projects report "coverage is set to 0% as no JaCoCo execution data has been dumped" and 0% code coverage is reported in the sonarqube dashboard. We have been able to get around this problem by using the following code snippet at the root pom.xml level | |
... | |
<plugins> | |
<plugin> | |
<groupId>org.apache.maven.plugins</groupId> | |
<artifactId>maven-surefire-plugin</artifactId> | |
<configuration> | |
<argLine>-Xmx1024m -XX:MaxPermSize=512m</argLine> | |
</configuration> | |
</plugin> | |
... | |
</plugins> | |
... | |
JaCoCo by default, uses the argLine content in maven-surefire-plugin to fork the jvm with the specified memory parameters during code coverage analysis. | |
Note: The above configuraiton is based upon Maven 3 build system operating with Oracle Java 1.7.0_25 | |
PS: After much of google help and reading blogs, the above configuration seems to be working fine for us and helping us report the correct coverage figures alongwith successful unit test execution. I thought it is worth sharing as my first gist contribution. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment