Support for aggregate task

[Kwestor]

Add support for report aggregation from multiple projects - it's already done in scalac-scoverage and sbt-scoverage and should be ported to gradle-scoverage.

I'm already working on it and when legal team gives me green light on PR I'll submit one.

[maiflai]

Hi - I raised scoverage/scalac-scoverage-plugin#81 to aid the sharing of code between the actual build plugins (I think there is duplication at the moment). I thought this would include the aggregation between multiple modules.

Is your PR for the gradle plugin, or does it cover multiple projects?

[gslowikowski]

This feature doesn't work at all. I told @sksamuel about it, but with no response.

[Kwestor]

My PR includes one file which calls CoverageAggregator.aggregate from scalac-scoverage.

@gslowikowski I think I have tested aggregation for multi-module sbt application and it worked.

[gslowikowski]

I can aggregare scoverage data (from xml files), but when I creage ScoverageHtmlWriter I have to pass sourceDirectory parameter. It's used to calculate relative paths from absolute paths written in scoverage data.
Lets say you have two modules foo and bar. So you have two paths to sources: foo/src/main/scala and bar/src/main/scala. What path will you pass to ScoverageHtmlWriter as sourceDirectory parameter value?

[gslowikowski]

... I mean when generating aggregated html report.

[Kwestor]

Yes, I have exactly this problem now with gradle, it merges two absolute paths and fails with java.io.FileNotFoundException.

[gslowikowski]

I see three related issues, I don't know if it's the best place to discuss it all, but anyway:

1. plugin should accept many source rootes for single project/module - this is common case
2. plugin should work when source files structure does not correspond to package names - very common case
3. project root in multimodule project should generate aggregated reports without knowing anything about module source roots.

I don't know, if package structure can be used instead of source files structure. If yes - problems solved (no need to calculate relative paths). In no - all these problems must be solved anyway, I don't know if it will be more complicated or not.

[gslowikowski]

I think that if 1. and 2. will be solved, solving 3. will be easy, but starting from 3. does not make sense IMO.
I don't know, how @sksamuel tested aggregate reports when he implemented it. Perhaps aggregate check and xml reports work, but html report does not work for sure.

[Kwestor]

I think I managed to "trick" scoverage to work with aggregate passing parent directory (of whole project) as a source dir if you run an aggregate task. I have to check if everything still works for standard projects, but it seems it's ok.

[gslowikowski]

It works at first sight, but such trick does not make sense. @sksamuel can you comment this?

[maiflai]

I think that's the way it's intended to be used - have you checked that you can follow all the links through to the source code?

[gslowikowski]

The links look good. I don't get it. Paths to all source files should have prefixes foo/src/main/scala and bar/src/main/scala (I have foo and bar modules). If these prefixes do not break the logic, that's weird to me. I must debug it.

[maiflai]

I think it works because it replaces the common element of all source paths - the root project directory.

I think it might not work if you have multiple levels of modules to merge together, but I've not tested that yet.