Maven goal report-aggregate should consider dependencies specified using version range

[metlos]

Fixes #657.

[marchof]

@Godin What do you think about this PR? Beside adding a test this looks good to me.

[metlos]

I've added an integration test heavily based on the it-report-aggregate. It should check that the jacoco files are loaded from locations of the projects in reactor that conform to the version range.

[Godin]

@marchof to be honest every implementation of aggregate reports for Maven look like workaround/hack for inflexible lifecycle of Maven build. And so I don't like them in general as a source of user confusions, misconfigurations, etc. This change looks like a continuation of workarounds/hacking. Nevertheless couple of more constructive comments here and inline in changes:

@metlos

I've added an integration test heavily based on the it-report-aggregate

I'm wondering why instead not simply update/extend it-report-aggregate? The reason of this question is that each integration test is very costly in terms of execution time, existing ones are already slowest part of our build and much slower than any other part. In Travis for latest build of this PR with JDK 8: 16.9 s for it-report-aggregate-version-ranges, 13.0 s for it-report-aggregate. Maybe will be even better to get rid / combine it-report-aggregate-customization, which was 9.5 s.

[Godin]

Can this ever happen?

[metlos]

Should not, really, but InvalidVersionSpecificationException is a checked exception, so there has to be something done about it...

[Godin]

If I'm not mistaken, then we use throw new AssertionError(e) for such things - e.g.

jacoco/org.jacoco.core/src/org/jacoco/core/data/ExecutionDataWriter.java

Line 123 in ce7de98

throw new AssertionError(e);

[metlos]

I'm wondering why instead not simply update/extend it-report-aggregate?

Well, I've seen another version of the report aggreate it-test - it-report-aggregate-customization and so I thought this was the approach you take. I can merge it into the main it-test if you wish..

[Godin]

For the record: during testing I stumbled upon a fact that when reactor contains two modules with same groupId:artifactId but of different versions (exactly like integration test), then first dependency which satisfies range will be picked. I.e. in case of range [0,2]

• if version 1 is before version 2 in reactor, then version 1 will be picked
• and vise versa - if version 2 is before version 1 in reactor, then version 2 will be picked

This looks acceptable to me - case seems rare, range can be narrowed/specified to select correct version from reactor.

[Godin]

@metlos thank you for your contribution which is now recorded in changelog ❤️