Hi Didier, the decision for using dependencies is based on two assumptions:
1) The user want to control the content of the aggregated report 2) The report can only be created after all modules have been compiled and there test have been executed. So it actually is a dependency and you cannot create a valid report if building its content fails. We took some notes about the design discussions we had at that time: https://github.com/jacoco/jacoco/wiki/MavenMultiModule <https://github.com/jacoco/jacoco/wiki/MavenMultiModule> Regards, -marc > On 1. Oct 2019, at 16:56, Didier Crest <[email protected]> > wrote: > > Dear JaCoCo Team, > > I have been using report aggregation in maven multi modules in order to > generate the code coverage report for multiple components. > > One behaviour I am struggling to understand what is the benefits of using > dependencies to access both the compiled code and the source code. I would > have assumed that the reactorMavenProjects would be used instead of the > dependencies. > > Note that the current behaviour has as side effect that if one of the module > packaging fail (no .jar produced) the aggregation report fail too. The code > coverage of the source code would still produce significant added value to > the user even if the packaging is failing. > > In order to produce the behaviour I am expecting, I cloned the tag 0.8.4 and > added the use of reactorMavenProjects object. The report produced is > consistent to the one produced with the dependency (in case no failure occurs > in the packaging phase) but is now allowing the generation of the report > without executing the packaging phase. Additionally, in case of project with > large number of sub module (e.g. >150) the presented approach does not > require the list of dependency in the scope of the report, but use the > inherited reactor execution plan, improving the maintainability of the > content of the report. > > I would like to know the rationales for the current implementation in order > to avoid degrading the performance my instance of JaCoCo. If you find the > behaviour I have implemented valuable, I would be glad to send a pull request. > > > > Didier Crest > DevOps Engineer > THALES SERVICES SAS > www.thalesgroup.com <http://www.thalesgroup.com/> > <image001.png> <http://www.thalesgroup.com/live> > > > > -- > You received this message because you are subscribed to the Google Groups > "JaCoCo and EclEmma Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jacoco/016201d57868%245acf88e0%24106e9aa0%24%40thales-services.fr > > <https://groups.google.com/d/msgid/jacoco/016201d57868%245acf88e0%24106e9aa0%24%40thales-services.fr?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/D1A0D5E8-4252-4F0A-A5D1-6B792C6C2411%40mountainminds.com.
