Allows the report mojo to reference binary/source files in other modules

[chrisruffalo]

I've been working with a multi-module report where I wanted the ability to create coverage reports based on the merged reports. I've really only been able to find good ways of doing this that all involve hacks.

So here's my counter-hack.

I'm not sure this would be accepted cleanly but I would appreciate some feedback.

Thanks!

[chrisruffalo]

I see the other pull request (#97) but I don't see any movement on it and wanted to maybe take a crack at doing it in a more simple way.

[marchof]

For multi-module reporting I would prefer to have a separate report bundle for every module. Not just merging all classes in into one bundle. Why?

• Better scalibility for hughe report (bundes are internally processed one after the other)
• The module structure is reflected in the report
• Different classes with the same name possible

[chrisruffalo]

My current understanding is that JaCoCo can only report, within a single module, on the test coverage produced by that module. If a class receives more test coverage (say from a separate integration-test module) then that test coverage would not appear as cumulative in the report.

Unless I'm mistaken about how it works.

So this change request is intended to address the use case where someone has merged test execution results (for example, using the merge goal) from multiple different modules or test executions.

This change replaces none of the old capability (which it should not based exactly on the reasons you gave) but augments it to allow for more diverse configurations.

Again, unless I'm missing some feature of the report generator that allows me to gain the type of report I'm looking for. I know that there is an aggregate-report feature but didn't see any direct references in the maven plugin code.

[marchof]

You're right: This is not yet there in the Maven code. The Ant task allows to create groups.

[chrisruffalo]

I see that you're working on that over in #97 but I didn't see any recent progress. This is more of an easy stopgap, I'll readily admit this is not the best solution.

[marchof]

Unfortunatelly this is a current restriction at the JaCoCo project: Due to the very limited resources we're very reluctant to add partial solutions where we expect more trouble afterwards.

[marchof]

We will go with a more generic solution as proposed in #97 or #388.