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

[rolandtritsch]

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.

[ckipp01]

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

Yea I think this is a good approach.

Thanks for the fix!

[Falmarri]

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.