Bug on jacoco import for multimodule project & class with same name/package in 2 modules

Hello everyone,

i noticed a strange behaviour with sonar 10.3 and jacoco code coverage with a jacoco-aggregate plugin (So i got 1 xml with all the report)

i generate a report aggregate, that’s just “right” and contains (little snippet) this block

    <group name="fabrickcore-spring-boot-k8sstarter">
        <package name="it/fabrick/core/starter/main/configuration">
            <class name="it/fabrick/core/starter/main/configuration/ReactorThreadContextLifterConfig"
                   sourcefilename="ReactorThreadContextLifterConfig.java">
......coverage info

    <group name="fabrickcore-spring-boot-starter">
        <package name="it/fabrick/core/starter/main/configuration">
            <class name="it/fabrick/core/starter/main/configuration/ReactorThreadContextLifterConfig"
                   sourcefilename="ReactorThreadContextLifterConfig.java">

....coverage info

the xml of course continue and it’s much biggger, there are also line coverage for ReactorThreadContextLifterConfig class inside group section.

now, the 2 classes are “similar” and are used as a replacement in case of k8s deploy OR on prem deploy, swapping the correct dependency in mvn (or using profile, for what it matter)

what happen is that during run of sonar i got

                             ERROR: Cannot import coverage information for file 'fabrickcore-spring-boot-starter/src/main/java/it/fabrick/core/starter/main/configuration/ReactorThreadContextLifterConfig.java', coverage data is invalid. Error: {}
                             java.lang.IllegalStateException: Line 30 is out of range in the file fabrickcore-spring-boot-starter/src/main/java/it/fabrick/core/starter/main/configuration/ReactorThreadContextLifterConfig.java (lines: 26)

that’s because it seems to use the ReactorThreadContextLifterConfig data from the other package :slight_smile:

so basically it’s mixing the result of the data, and this block the import of code coverage. i can say that

as a side note, ReactorThreadContextLifterConfig from base packag e is 26 lines (including spaces)
and the other form k8s package is 39, and on line 30 i surely have a test running (checked), i am quite confident that the exception “line 30 out of range line 26” refer to the fact that the line 30 of k8s package is used to track coverage of the smaller other version

aside from renaming the classes, what other option i have?
am i doing anything wrong?

where do user report bug for sonar?

Hello @Rama_Rama,

If you’re using an aggregated report and have 2 classes with the same name and same package, there’s indeed no guarantee to pick up the right one during reading and reporting the coverage result as that’s what we see in the Jacoco report.

I would also like to ask you to check the JaCoCo HTML report to understand if JaCoCo itself is able to locate files correctly (When you click on the class name in the HTML report, which class it actually shows).

In my team. we will think about what we can do with the issue, however, note, that you’re using 2 practices, that are discouraged being used together:

  • Aggregated reports
  • classes with the same name and package in different modules

Thanks for the report this is sort of a known issue, maybe we can think about a better error message. If I am not mistaken, it shouldn’t crash the whole analysis. If it does, provide us a full log and we will fix this.

Best,
Margarita