The file has no scoverage information associated with it.

[dmarkhas]

We're using version 6.2.0 of the plugin, but when running the sonarqube task from Gradle it seems that it somehow fails to parse the scoverage.xml report, even though it finds it and loads it successfully.

These are the errors I am seeing:

[scoverage] Initializing the scoverage sensor.
[scoverage] Successfully loaded the scoverage report file: 'C:\Users\dmarkhas\IdeaProjects\sdk-base\build\reports\scoverage\scoverage.xml'.
[scoverage] The file: 'src/main/scala/com/intel/daas/sdk/Launcher.scala' has no scoverage information associated with it.
[scoverage] The file: 'src/main/scala/com/intel/daas/sdk/application/AbstractSparkApplication.scala' has no scoverage information associated with it.
[scoverage] The file: 'src/main/scala/com/intel/daas/sdk/application/ApplicationContext.scala' has no scoverage information associated with it.

I saw #51 but in this case the filenames match exactly the filenames in the xml report so I'm not sure what's wrong. I've attached the scoverage report (had to rename from .xml to .txt for GitHub) - anything obvious I am missing perhaps?

scoverage.txt

[BalmungSan]

Hello @dmarkhas, could you run the plugin in debug mode and paste the output here?

But, probably the issue is due you're running on windows, and the ScoverageSensor does not support windows yet!.

(@mwz, IMHO, we should focus on fixing the incompatibility with windows ASAP.)

[dmarkhas]

I thought so too, but running it on Linux resulted in the same issue. I am now playing around with the code a bit and it seems that the moduleCoverage.filesCoverage map is empty.
I believe it is a bug introduced by this commit: 7173142#diff-6bfed6247dd6c81a3cc573964ccf73b3

Specifically, this piece of code in ScoverageReportParser seems to be at fault:

      filename <- sourcePrefixes.collectFirst {
        case prefix if cwd.resolve(prefix).resolve(scoverageFilename).toFile.exists =>
          prefix.resolve(scoverageFilename)
      }

Given the following parameters:
sourcePrefixes : ["src/main/scala"]
scoverageFilename : "src/main/scala/com/intel/daas/sdk/application/ApplicationContext.scala"

This tries to resolve the path cwd/src/main/scala/src/main/scala/com/intel/daas/sdk/application/ApplicationContext.scala

Which is wrong, since the filename already contains the prefix :)

[BalmungSan]

Uhm... yes, you're right. Could you try the following piece of code?

filename <- sourcePrefixes.collectFirst {
  case prefix if cwd.relativize(cwd.resolve(Paths.get(prefix))).relativize(Paths.get(scoverageFilename)).toFile.exists =>
    cwd.relativize(cwd.resolve(Paths.get(prefix))).resolve(scoverageFilename)
}

[dmarkhas]

That doesn't compile for me.. I assume you're using java.nio.file.Paths? in that case the get method accepts either a String or a URI, while prefix is Path. I tried prefix.toURI and that didn't work..

[BalmungSan]

Oh sorry I forgot that, you could use prefix.toString.

Edit
Oh wait, prefix is already a Path so Paths.get(prefix) is unnecessary. Thus the code becomes:

filename <- sourcePrefixes.collectFirst {
  case prefix if cwd.relativize(cwd.resolve(prefix)).relativize(Paths.get(scoverageFilename)).toFile.exists =>
    cwd.relativize(cwd.resolve(prefix)).resolve(scoverageFilename)
}

I'm sorry for the confusion. Could you try it again?

PS: This is just for making a quick test/fix. I will make PR for fixing this in a couple of days.

[dmarkhas]

Unfortunately that didn't work. I think the underlying issue is that the filename in the scoverage.xml already contains the prefix "src/main/scala", making the prefix actually redundant.
In my case, simply checking if cwd.resolve(scoverageFilename) exists is sufficient, and then simply setting filename to be scoverageFilename works.

No changes would be needed if there was any way to remove this prefix from the filename in the generated scoverage.xml report, but there doesn't seem to be any such option in the gradle plugin.

[BalmungSan]

Yes, you're right.
I'm sorry, I'm a bit busy so I not taking the time to look at this properly thus I got confused 😞.

We're having a big problem here:
When using SBT the scoverage filenames are relative to "src/main/scala".
When using Gradle they are relative to the project root.
When using Maven they are absolute path.
Also they are dependent to the SO ('\' vs '/').

Uhm...
This will be difficult to handle.

@mwz Any thoughts?

@dmarkhas, sorry again for not being of much help, when I have time I will work in this.

[dmarkhas]

I really appreciate your help :-)
In the meanwhile we can keep using my simplified forked version.

Perhaps checking if the scoverageFilename begins with the prefix and then stripping it out would work?

[mwz]

Hi @dmarkhas, thanks for reporting the issue. It sounds like your suggestion to strip out the prefix from the filename should work, so it's worth giving it a try.

It's a shame that there are so many inconsistencies between different distributions of sonar scanners and scoverage plugins... this certainly doesn't make our life easier and it starts slowly to feel like we're doing cross-browser development 😆

[mwz]

@dmarkhas, thanks for waiting and testing the latest changes in #57 - I'll make a new release as soon as #54 gets merged.

[mwz]

@dmarkhas - 6.3.0 is out. Feel free to let us know if you have any more issues.

[freshka]

Problem occurs for multi modules projects (works properly for projects without modules)

sonar-project.properties:
sonar.modules=output-adapter,commons
sonar.scala.scoverage.reportPath=build/reports/scoverage/scoverage.xml

output:
12:02:17.765 INFO: [scoverage] Successfully loaded the scoverage report file: 'output-adapter/build/reports/scoverage/scoverage.xml'.
12:02:17.765 DEBUG: [scoverage] Saving the overall scoverage information about the module, the statement coverage is 97.56%.
12:02:17.767 DEBUG: [scoverage] Saving the scoverage information of the file: 'output-adapter/src/main/scala/dummy/adapter/output/CepTicketProvider.scala'
12:02:17.767 WARN: [scoverage] The file: 'output-adapter/src/main/scala/dummy/adapter/output/CepTicketProvider.scala' has no scoverage information associated with it.

[mwz]

Hi @freshka, thanks for letting us know that you're having issues.

Would you mind sharing with us some more details about your setup like e.g. which build tool you're using, how your multi-module project is structured, your full sonar-project.properties file and how you're executing the analysis?

Would you also be able to confirm that you've set the sonar.scala.scoverage.reportPath property for each module and that Scoverage generates a report within each module and you're not aggregating the reports into one?

[freshka]

Hi @mwz
I'm using Gradle with gradle-scoverage:2.3.0

Project structure example:

commons
--src
----main
----test
--build.gradle
output-adapter
--src
----main
----test
--build.gradle
build.gradle
settings.gradle (include all modules here)

Analize execute by Jenkins (SonarQube Scanner v. 3.0.3.778) and scoverage reports not aggregated. Sonar-scala plugin cannot find files but properly read report as i said above:
12:02:17.765 DEBUG: [scoverage] Saving the overall scoverage information about the module, the statement coverage is 97.56%.

sonar-project.properties:
sonar.projectKey=cep_adapter
sonar.projectVersion=01.003
sonar.modules=output-adapter,commons
sonar.sources=src/main/scala
sonar.tests=src/test/scala
sonar.java.binaries=build/classes/main,build/classes/test
sonar.scala.scoverage.reportPath=build/reports/scoverage/scoverage.xml
sonar.sourceEncoding=UTF-8
sonar.locale=ru_RU

[BalmungSan]

Hello @freshka,

If the reports are not aggregated, that means there is one report per module, is that correct?

Also, could you please provide us one of the scoverage files? (If they contain sensitive information that you wouldn't like to share, we only need the filename attribute of one class tag)

[freshka]

Hi @BalmungSan
Yes, one scoverage report per module, report located in a module directory (for example output-adapter/build/reports/scoverage/scoverage.xml)

<class name="dummy.adapter.output.CepTicketProvider" filename="src/main/scala/dummy/adapter/output/CepTicketProvider.scala" statement-count="36" statements-invoked="36" statement-rate="100.00" branch-rate="100.00">

filename is relative to module path, not to project root

[sinwe]

The issue that @freshka encounter is exactly the same as mine. I'm waiting for the fix of this

[mwz]

Hi @freshka, @sinwe - apologies for the wait. I've merged a fix for your issues and am hoping to do a little bit more testing against any regressions, but you can expect a new release most likely sometime over the weekend.

[sinwe]

@mwz I appreciate the effort you've put into it. I'll wait for the new release

[mwz]

@sinwe, @freshka, just to let you know that 6.4.0 was released a couple of days ago and it should fix your Gradle issues with multi-module projects.

You can also find an example of a multi-module project built with Gradle here and here is the result of SonarQube analysis with coverage reported for each module.

Thanks again for reporting the issue and please feel free to let us know if you come across anything else.