Uploaded image for project: 'Product Roadmaps'
  1. Product Roadmaps
  2. MMF-1651

Deprecate JaCoCo .exec file format support in SonarJava

    Details

    • Type: MMF
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Fix Version/s: None
    • Labels:

      Description

      WHY

      SonarJava is supporting the JaCoCo .exec file format since almost the beginning of the history of SonarJava. This feature is only compatible with .java files.
      SonarQube is now providing the JaCoCo Plugin supporting the JaCoCo XML format. This plugin is compatible with whatever files compatible with JaCoCo.

      We have two ways to load coverage data generated by JaCoCo for Java projects: thru the .exec or thru the XML file.

      We know that the .exec file is not an exchange format. This is an internal format used by JaCoCo developers. It is not at all recommended to use it for integration purpose.

      Because of that, we want to get rid of the support of the .exec file format and rely only on the XML one.

      WHAT

      SonarJava Impact

      The property sonar.jacoco.reportPaths will be deprecated. When it is set a message is written in the logs and in the UI of SQ saying:

      WARN: "sonar.jacoco.reportPaths" is deprecated (JaCoCo binary format). "sonar.coverage.jacoco.xmlReportPaths" should be used instead (JaCoCo XML format).

      When both "sonar.jacoco.reportPaths" and "sonar.coverage.jacoco.xmlReportPaths" are set a message is written to say that only the XML one will be taken into account:

      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.

      When coverage by test is activated (listener is configured in the pom.xml?) a WARN message should be written in the logs and a WARN in the UI if SQ >= 7.4

      WARN: "Coverage per Test" is deprecated. Consider removing XZY listener configuration.

      When running on SQ >= 7.7:

      WARN: "Coverage per Test" feature was removed from SonarQube. Remove XZY listener configuration.

      Message for the following old deprecated properties should be adjusted to also refer to the XML report import:

      The message should also be displayed in the SonarQube UI.

      Scanners Impact

      SonarScanner for Gradle
      => We need to set by default the property "sonar.coverage.jacoco.xmlReportPaths" if the Gradle Jacoco Report task is configured in the "build.gradle".
      "SonarScanner for Gradle" will continue to set the deprecated "sonar.jacoco.reportPaths", "sonar.jacoco.reportPath" and "sonar.jacoco.itReportPath" properties for backward compatibility reason.

      SonarScanner for Maven
      => Nothing to do. Default values are coming from SonarJava.

      SonarScanner for Jenkins
      => Nothing to do.

      SonarScanner for VSTS
      => There is an hardcoded default version 2.6.2 of the SQ Gradle Task. We decided to keep it like this because it's possible for the user to set a specific version.
      => Nothing to do.

      Migration Path for Maven User

      Remove any "sonar.jacoco.itReportPath" or "sonar.jacoco.reportPath" or "sonar.jacoco.reportMissing.force.zero" from your pom.xml files.

      Add "sonar.coverage.jacoco.xmlReportPaths" listing all the locations where your build is generating JaCoCo xml files in case you don't rely on the default location: "target/site/jacoco".

      Use "jacoco-maven-plugin" Maven Plugin and its "report" task: https://www.eclemma.org/jacoco/trunk/doc/report-mojo.html

      mvn clean org.jacoco:jacoco-maven-plugin:prepare-agent org.jacoco:jacoco-maven-plugin:report install -Dmaven.test.failure.ignore=false
      

      Migration Path for Gradle User

      Configure the Gradle Jacoco Report

      Use the latest version of the SonarScanner for Gradle: >= 2.8+

      Documentation and Examples Impacts

      We need to update:

      Drop of JaCoCo .exec file format support

      This is scheduled in 6 months, around Sept 2019.

      HOW

      First the SonarScanner for Gradle will be upgraded thanks to: SONARGRADL-60
      Then SonarJava will be upgraded.

      We will use the newer versions at SonarSource and that will be a way to validate that the migration paths are correct.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                alexandre.gigleux Alexandre Gigleux
                Reporter:
                alexandre.gigleux Alexandre Gigleux
              • Votes:
                0 Vote for this issue
                Watchers:
                6 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: