sonar.coverage.jacoco.xmlReportPaths is not showing code coverage while sonar.jacoco.reportPaths shows code coverage

[ShreyashPromact]

Here I am using Jococo Android Plugin
When I use sonar.jacoco.reportPaths for my Android Project to report code coverage it shows the coverage properly, but when I use sonar.coverage.jacoco.xmlReportPaths then it is not showing coverage for the same code on sonarQube. Either there is an issue with the format provided by Jococo & SonarQube for the Code Coverage file.

Steps to reproduce

A configured project with the deprecated property of Sonar, that is sonar.jacoco.reportPaths, You will get Warning on SonarQube server to use a new property instead of the deprecated ones. You can also see the code coverage ersults on SonarQube. Now use the new property sonar.coverage.jacoco.xmlReportPaths & comment the deprecated property sonar.jacoco.reportPaths. Now, execute the analysis on sonarQube. See that the code coverage is 0.0% on SonarQube server.

JaCoCo version: com.dicedmelon.gradle:jacoco-android:0.1.4
Operating system: Windows 10
Tool integration: Gradle/Java, toolVersion: "0.8.3"

Expected behavior

It should generate and upload the code-coverage report in a supported format so that sonarQube can identify the code-coverage of the code.

Actual behavior

It is showing 0.0% code-coverage on sonarQube with sonar.coverage.jacoco.xmlReportPaths.

[Godin]

According to page https://github.com/arturdm/jacoco-android-gradle-plugin seems that com.dicedmelon.gradle:jacoco-android allows to produce not only execution data in "exec" files for the deprecated in SonarQube property sonar.jacoco.reportPaths, but also XML reports that are required for the new property sonar.coverage.jacoco.xmlReportPaths.

And in any case com.dicedmelon.gradle:jacoco-android as well as SonarQube integration are not developed/maintained by us - problems with third-party integrations should be discussed with their corresponding vendors.

Thank you for your understanding.

[ShreyashPromact]

@Godin
Looking at the above comments, it looks like conflict to me. SonarQube is using jacoco property and it is not producing the valid formate as said by them. Please review this for same.
https://community.sonarsource.com/t/sonar-coverage-jacoco-xmlreportpaths-not-showing-code-coverage-but-the-deprecated-sonar-jacoco-reportpaths-shows-code-coverage/12938/10

Now, where is the issue? Not jacoco team nor sonarQube team is addressing this.
Please have a look at it and consider this.
Thanks.

[Godin]

@ShreyashPromact

SonarQube is using jacoco property

Properties sonar.jacoco.reportPaths and sonar.coverage.jacoco.xmlReportPaths are not defined by https://github.com/jacoco/jacoco project - they both defined in SonarQube plugins:

• sonar.jacoco.reportPaths is defined in https://github.com/SonarSource/sonar-java/blob/5.14.0.18788/java-jacoco/src/main/java/org/sonar/plugins/jacoco/JaCoCoSensor.java#L52

• sonar.coverage.jacoco.xmlReportPaths is defined in https://github.com/SonarSource/sonar-jacoco/blob/1.0.2.475/src/main/java/org/sonar/plugins/jacoco/ReportPathsProvider.java#L33

---

Now, where is the issue?

First of all - let's understand the fundamental difference between "exec" file and XML report.

JaCoCo allows to collect information about execution of code into so called "exec" file. This file is not final report, it does not contain information about lines - this file must be analyzed together with class files to obtain information about coverage of lines and branches. XML report is the result of such analysis and contains information about coverage of lines and branches.

You configure and use third-party Gradle plugin https://github.com/arturdm/jacoco-android-gradle-plugin aka com.dicedmelon.gradle:jacoco-android that calls JaCoCo library to perform such analysis to generate XML and HTML reports according to configuration of this Gradle plugin.

When you use sonar.jacoco.reportPaths=file.exec for module a, third-party SonarQube integration also calls JaCoCo library to perform such analysis using class files of module a and file.exec to compute lines coverage for source files in module a.

When you use sonar.coverage.jacoco.xmlReportPaths=report.xml for module a, SonarQube will use already computed values from report.xml for source files in module a.

---

is not producing the valid formate

As far as I can see, this is absolutely not what was said in https://community.sonarsource.com/t/sonar-coverage-jacoco-xmlreportpaths-not-showing-code-coverage-but-the-deprecated-sonar-jacoco-reportpaths-shows-code-coverage/12938/10

What was said multiple times by @saberduck - is that you should spend time to carefully compare values:

HTML report contains the same values as XML since they both are generated by the same Gradle plugin com.dicedmelon.gradle:jacoco-android by using the same configuration and at the same time.

If HTML and XML reports do not show values that you expect to see, then your problem is likely in misconfiguration of com.dicedmelon.gradle:jacoco-android.

If HTML and XML reports show expected values, but not the same as in SonarQube with sonar.coverage.jacoco.xmlReportPaths, then your problem is likely in misconfiguration of this SonarQube property.

If values are different and unexpected everywhere, then most likely you have misconfiguration in multiple places, and in this case please first fix configuration to get expected values in XML report.

For better understanding in which module and which configuration is missing, please compare values for individual source files and not just totals.

---

Here is example: for JaCoCo project itself we produce HTML (https://www.eclemma.org/jacoco/trunk/coverage/) and XML (https://www.eclemma.org/jacoco/trunk/coverage/jacoco.xml) reports, and all modules are configured to import exactly this XML report into SonarQube (6babdb5), as like for any file comparison of line coverage for source file MergeTask.java shows that the value is the same

---

I hope that the above explanations are clear enough to do such comparison by yourself. Otherwise please provide complete example of project demonstrating your difficulty, because only in this case such comparison can be done by someone else than you. And only in this case our very small JaCoCo Team can consider to try to find time on questions regarding misconfiguration of third-party integrations.

Thanks you for your understanding.

[ShreyashPromact]

@Godin

First of all, Thanks a lot for spending some time and giving such a nice explanation. It seems I need to check towards the configuration and library. I might post a message here in case I need some help from you.

Again, thanks a lot for your explanation and understanding the issue. It's really appreciated.
Thanks.

[mochadwi]

In my case, as stated here the SonarQube and JaCoCo must be configured correctly.

E.g:

• For the demo purpose, I'm just trying to keep constants package only for the coverage and exclude everything.

• Jacoco has exclusions to class/package for everything, example code image below

• Sonarqube property haven't used any sonar.exclusion=[regex], in fact, it will keep showing the "overall" report for all of our files in sonar.sources=path/to/main/src, that will be decreasing everything to 0%.

• Here's the result, sonarqube keep the other package even we already "exclude" the everything except constant package from Jacoco

• So, make sure to configure both exclusions correctly as well. And also make sure to run task test related first then sonarqube task. That way you won't find this warning: Report doesn't exist: [file/to/xml report]

Thanks for @Godin for a detail explanation about this. Also @ShreyashPromact for creating this issue on sonarqube community and here.

I've also scratched my heads about this configuration. Hopefully someone able to grasp it.