SonarJava 5.13.1.18282 silently ignores JaCoCo XML report

SonarQube Server / Community Build
,
1

Versions used

  • SonarQube version 6.7.7
  • SonarJava version 5.13.1.18282

The JaCoCoSensor sensor in SonarJava project has deprecated the property sonar.jacoco.reportPaths in favor of sonar.coverage.jacoco.xmlReportPaths which is silently ignored and not analyzed.

To make things worse sonar.coverage.jacoco.xmlReportPaths is defined by default, meaning that if such an XML report exists in any of the default locations (in e.g. target/site/jacoco/jacoco.xml in Maven builds) it will override all deprecated reports (such as jacoco.exec).

Steps to reproduce

The behaviour can be observed in the following Maven setups:

Without sonar.jacoco.reportPaths property

  1. Using jacoco-maven-plugin generate report with the report goal. This generates both an HTML and an XML report.
  2. Invoke sonar-scanner in debug mode, the following log will be printed:
09:33:20.940 INFO: Sensor JaCoCoSensor [java]
09:33:20.944 DEBUG: JaCoCo XML report found, skipping processing of binary JaCoCo exec report.
09:33:20.944 INFO: Sensor JaCoCoSensor [java] (done) | time=4ms
  1. Coverage is set to 0.0% in SonarQube

With sonar.jacoco.reportPaths property

  1. Using jacoco-maven-plugin generate report with the report goal. Once again this generates both and HTML and XML report.
  2. Invoke sonar-scanner in debug mode, the following log will be printed:
09:35:52.190 INFO: Sensor JaCoCoSensor [java]
09:35:52.194 INFO: Both 'sonar.jacoco.reportPaths' and 'sonar.coverage.jacoco.xmlReportPaths' were set. 'sonar.jacoco.reportPaths' is deprecated therefore, only 'sonar.coverage.jacoco.xmlReportPaths' will be taken into account.
09:35:52.194 DEBUG: JaCoCo XML report found, skipping processing of binary JaCoCo exec report.
09:35:52.194 INFO: Sensor JaCoCoSensor [java] (done) | time=4ms
  1. Coverage is once again set to 0.0% in SonarQube.

Workarounds

So far the only workaround Iā€™ve found is by eitherā€¦

  1. ā€¦ not generating a report at all (i.e. run only prepare-agent goal) orā€¦
  2. ā€¦ removing the generated XML report manually

Both are suboptimal solutions, as for debugging purposes we would still like to store the HTML report, but do not want to make workaround steps in our otherwise robust CI pipelines.

Either way, by not having the XML report around we can observe the following log:

09:42:14.172 INFO: Sensor JaCoCoSensor [java]
09:42:14.176 WARN: Property 'sonar.jacoco.reportPaths' is deprecated (JaCoCo binary format). 'sonar.coverage.jacoco.xmlReportPaths' should be used instead (JaCoCo XML format).
09:42:14.197 INFO: Analysing C:\Users\elindqvi\Repositories\service-orchestration\altiplano-driver\target\jacoco.exec
09:42:14.306 INFO: Sensor JaCoCoSensor [java] (done) | time=134ms

and finally get the appropriate coverage percent in SonarQube.

Other workaround is to install sonar-jacoco plugin (which ā€” as far as I can see ā€” has fixed the issue) for SonarQube, but unfortunately Iā€™m not our SonarQube instance administrator.

2

Maybe a stupid question, but can you ask your instance administrator?

3

I can. Although in a big company like ours, changes happen very slowly.

4

You can tell them that support for importing the .exec format at all will be removed in the next major version of SonarJava, so the sooner they let people import the XML format the less pain there will be for them down the line! :smiley:

That aside, Iā€™ll be honest that I also find this a little sub-optimal. However it is also a temporary pain and pushes users to move to the XML format sooner if theyā€™re already generating the correct reports.

5

hello @Eetami,

do you know why XML report doesnā€™t produce coverage information in SonarQube? When we deprecated the binary report we designed it this way, because it seems to me that using XML report is always superior to the binary report. So I would like to understand why binary report works and XML report doesnā€™t in your case.

6

Itā€™s because SonarJavaā€™s JaCoCoSensor does not actually process the XML report at all, but instead delegates that to JaCoCo plugin that has its own JacocoSensor implementation as well.

Though I feel dumb now that our SonarQube administrator installed the JaCoCo plugin 5 seconds after I sent a support request. So for us this issue is fixed.

I propose that SonarJava plugin would handle the situation by printing a clear notification that JaCoCo plugin is needed for processing XML reports.

7

Ok, I overlooked that you are on 6.7. where sonar-jacoco is not shipped by default. Indeed this will happen when the plugin processing XML report is missing. We decided to accept it, as it should not concern so many users and there is easy workaround (installing the plugin).

9

I created following ticket to improve the log message to mention that sonar-jacoco is required to process the XML report

https://jira.sonarsource.com/browse/SONARJAVA-3164

1 Like
11

I donā€™t think there is an easy workaround.
Iā€™m on SonarQube 6.7.1. The JaCoCo plugin available in Marketplace is 1.1.0 (build 898). When I try to install it says: ā€œError while downloading plugin ā€˜jacocoā€™ with version ā€˜1.1ā€™. No compatible plugin found.ā€

So Iā€™m stuck. I canā€™t use neither javococo.exec nor jacoco.xml. :frowning:

12

As stated here looks like old releases are removed after 18 months soā€¦
Can I download and install ā€œmanuallyā€ and old plugin version?

13

Ummā€¦ looks like I can manually download a compatible version from https://binaries.sonarsource.com/Distribution/sonar-jacoco-plugin/sonar-jacoco-plugin-1.0.2.475.jar and then put it inside $SONARQUBE_HOME/extensions/plugins
:thinking:

Also seen at Manual install - Download link

14

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.