Support multiple source roots in report generators

[gslowikowski]

All supported build tools (SBT, Gradle and Maven) support multiple source roots, but Scoverage requires only one sourceDirectory passed to ScoverageHtmlWriter and ScoverageXmlWriter.

I've prepared working prototype with solution to this limitation. Let me commit everything first and then I will comment what we will gain (this will fix many different bugs reported).

[gslowikowski]

I've forked Scalac plugin repo to https://github.com/gslowikowski/scalac-scoverage-plugin/tree/issue104, required changes are in commit gslowikowski@24039a2

What's in this revision:

1. Multiple source roots support - sourceDirectories: Seq[File] instead of sourceDirectory: File in ScoverageHtmlWriter and ScoverageXmlWriter reporters constructors (I didn't touch CoberturaXmlWriter, I don't know if should be changed, there is baseDir parameter instead of sourceDirectory)
2. Small, but very important change - if no source root is found for a file, exception (what class should it be?) is thrown. This prevents from creating not proper paths (many issues report this problem in different contexts) and works according to "fail fast" rule.
3. version changed to "1.0.5-SNAPSHOT".

I've forked Maven plugin repo to https://github.com/gslowikowski/scoverage-maven-plugin/tree/issue104, required changes are in commit gslowikowski/scoverage-maven-plugin@d9076f8

Because source roots can be added dynamically during the build, they should be stored somewhere just before compilation because:

• report generation can be executed in separate Maven invocation (mvn report-only) and in that invocation full build process will not be performed, so dynamically added source roots will not be known; I would prefer to store these paths inside scoverage.coverage.xml file but this would require passing additional parameter to scalac
• aggregated report gathers source roots from all modules (without this root module doesn't know anything about child modules' source roots)

The last forked repository https://github.com/gslowikowski/scoverage-maven-samples/tree/issue104 contains changed Maven sample projects working with the above two (Scalac and Maven) patched libraries.
Interesting samples:

1. https://github.com/gslowikowski/scoverage-maven-samples/tree/issue104/aggregator - aggregated report with proper internal locations and links.
2. https://github.com/gslowikowski/scoverage-maven-samples/tree/issue104/playframework/singlemodule - four similar Play! Framework projects having two source roots each: app and target/src_managed/main. The second one contains Scala sources generated from Play! templates (in app/views directory). Scoverage report shows coverage for classes from both locations.
   Instructions, how to generate Scoverage reports are in readme-scoverage.txt files.

OK, that's all for today. I would like to discuss this feature. This seems to be trivial, but it's not. I thought about this since long time and this must be implemented IMO sooner or later. There are many issues reported which will be fixed. Check my code, please, and write what you think about it.

[maiflai]

thanks for this - re: multiple source roots - I agree that there are multiple source roots per project, but I don't agree that it is appropriate to squash the HTML files to the package level. Scala is not as restrictive as Java; two files can share the same name and location in the 'package' structure yet contain different classes.

I do agree that the report should fail if the source file cannot be found.

[maiflai]

re: the path of the generated HTML files, it's been my recent experience that web browsers now hide the finer details of the URL from users. For example, my browser is displaying 'GitHub, Inc.' rather than the full https://github.com/scoverage/scalac-scoverage-plugin/issues/104

[gslowikowski]

I've created PR for this issue. PRs for SBT and Maven will be created in a moment. Everything works as expected.

One change (gslowikowski@f3a6489) is not backward compatible. This was done intentionally. In IOUtils.relativeSource if no source root is a parent of specified file, exception is thrown instead of returning absolute path as was before. Failing fast is better than failing later with strange java.io.FileNotFoundException caused by illegal path.

[Kwestor]

Yaay, this should resolve some of my problems with scoverage ! Thanks Grzegorz.

[gslowikowski]

@sksamuel can you review my PRs for this issue: #109 + scoverage/sbt-scoverage#98 ?

[travisbrown]

Coveralls doesn't like relative paths for filenames for classes in the Cobertura report. Is there a workaround for this? If not I'm happy to file an issue. Thanks!

[gslowikowski]

I've prepared https://github.com/gslowikowski/sbt-coveralls/commits/scoverage-1_1_x-compatibility. This, ore something similar, should be implemented for future sbt-coveralls 1.1.0 release.

@rorygraves, this is for you. I did it some time ago. If I remember, you said, you will work on this too. I have no time to test it yet.