Maven :report-aggregate support transitive reactor deps

[ls-urs-keller]

Scenario

• JaCoCo version: 0.8.7
• Operating system: All
• Tool integration: Maven
• Description of your use case: multi module project with transitive deps

Current Behaviour

Assume we have the following project structure:

• commons/pom.xml
• commons/src/main/xyz/Util.java
• service/pom.xml
• it/pom.xml
• pom.xml

Assume a test in it that covers a class xyz/Util.java in commons, the transitive dependency to this class is it->service->commons, then the coverage report in it will have no coverage for xyz/Util.java.
Testcase here: 2c58ab3

Wanted Behaviour

An aggregated coverage report should also resolve transitive dependencies within the reactor. Currently only 1 level of dependencies for each project is resolved against the reactor (MavenProject#getDependencies instead of MavenProject#getArtifacts)

Possible Workarounds

A workaround would be:

• configure a report project and enumerate all dependencies
• don't use transitive deps to reactor deps, add them even if they are added transitively

PR #1242

[ls-urs-keller]

Suggested pull request, however not sure I understand the original intention of this:

	 * Note that if dependency specified using version range and reactor
	 * contains multiple modules with same artifactId and groupId but of
	 * different versions, then first dependency which matches range will be
	 * selected. For example in case of range <code>[0,2]</code> if version 1 is
	 * before version 2 in reactor, then version 1 will be selected.
	 */

The project in the reactor will always have a fixed version, no range.
The dependency might have a version range. If that dependency points to the same version as present in the reactor then all is good.

Are there cases where a dependency should be covered from within the reactor but pointing to a version different from the reactor?

E.g. consider the following case:

• checked out project at version 1
• the project has also version 2 and it is published to maven
• in project version 1, a dependency range to a dependency within the reactor is used e.g. [1,100)
• this would mean that even when building 1 the project will take version 2 for a dependency, since maven would resolve the newer version
• this would then mean that we are trying to report coverage from version 2 of the dep to the source of version 1

Not sure if my analysis is correct and whether this makes sense.

Does it really make sense to try to report coverage if the instrumented classes and the source have different versions?

[JayDi85]

It’s a very useful feature - use of maven’s reactor to collect all dependencies of multi-modules project. It’s hard to manually research and add all modules dependencies to the aggregation project (there are possible hundreds of deps).

Jacoco must collect all dependencies from listed modules by default without any hacks or workaround like #1251 (comment)

[tircis]

Hi,
Since I was struggling with same problem (Jacoco plugin doesn't following maven's reactor to collect its dependencies, in particular with multi-modules project), and reading a bunch of articles, i decided to fix it on my own with a dedicated maven-plugin that mimics Jacoco official one. @JayDi85 you may have a look at it and give me some feedback about it : jacoco-aggregate-submodule

[wingice]

Yes. It'd better to use maven's reactor to collect all dependencies of multi-modules project instead of creating a new module to hold all the dependent-modules. Because we have a very large project with 30+ modules. It is very inconvenient.