search

scoverage / scalac-scoverage-plugin

Scoverage Scala Code Coverage Core Libs
https://github.com/scoverage
Apache License 2.0
423 stars 126 forks source link

Bug Fix: sbt-coveralls: Issue 199: Use relative paths in cobertura.xml file #497

Closed rolandtritsch closed 1 year ago

rolandtritsch commented 1 year ago

Hi @ckipp01. Here is the proposed bug-fix for issue 199 on sbt-coveralls.

One way to fix this is to make sure that Location.source is NOT using the canonical path, but I do not know what else relies on it.

Means the less risky fix was to use relativeSource from the BaseReportWriter. This is what the other report writers are doing.

I also tested this with by rebuilding sbt-scoverage with a local build of the fixed scala-scoverage-plugin.

Falmarri commented 10 months ago

This is a bad change. Now there's no way to determine the actual source to the class in question. For example, a project can have multiple definitions:

        <source>/home/user/project/subproject/src/main/scala</source>
        <source>/home/user/project/subproject/target/scala-2.12/src_managed/main</source>

and then an example class

<class name="com.org.package.ClassName" filename="com/org/package/ClassName.scala" line-rate="0.00" branch-rate="0.00" complexity="0">

This is especially difficult when using sbt-scoverage to aggregate the subprojects. That just concats all the sources into 1, making the aggregated report basically useless. How do I determine where that class is from? I can likely figure it out because of requirements of scala, that there can't be multiple class names in the same package. But the information provided does not tell me where to find the class. I could have a file in each of those 2 source directories called com/org/package/ClassName.scala, but they provide different class names. I'd have to open the file and try to parse it to determine which file is the actual source of this class.