jacoco-maven-plugin: aggregated report empty with separate aggregation and inheritance pom

11,537 views
Skip to first unread message

em....@gmail.com

unread,
Jul 12, 2016, 6:33:00 AM7/12/16
to JaCoCo and EclEmma Users
Hi,

As described here:
https://github.com/jacoco/jacoco/pull/388#issuecomment-211578936
I understood that I should have a separate aggregator pom and inheritance pom. My project layout is now as follows:

aggregator pom
|- parent pom
|- module a
|- module b

In the parent pom, I've configured the Jacoco agent for coverage data collection, and I've configured a per-module report:

<reportSets>
<reportSet>
<id>default</id>
<reports>
<report>report</report>
</reports>
</reportSet>
</reportSets>

This works as expected, module a and module b each get a coverage report for only this module.

In the aggregator pom, I've configured an aggregated report:


<reportSets>
<reportSet>
<id>aggregate</id>
<reports>
<report>report-aggregate</report>
</reports>
</reportSet>
</reportSets>

However, this results in an empty report. It seems that the plugin doesn't know that it should collect the execution data files from module a and module b. How should I tell it where to find all execution data files? Using dependencies is probably not the way to go, since the whole idea is that the aggregator pom has no dependencies, only the parent pom is part of the dependency cycle!

Regards,

Michel.

Marc Hoffmann

unread,
Jul 12, 2016, 10:55:35 AM7/12/16
to jac...@googlegroups.com
Hi,

the aggregator project does not work as a container for the coverage
report, unfortunatelly it is build *before* its modules. Therefore the
report is empty. You need a separate project which the projects under
test do not depend on:

aggregator pom
|- parent pom
|- module a
|- module b
|- report module

Where "report module" has a dependency on module a and b.

Regards,
-marc

em....@gmail.com

unread,
Jul 13, 2016, 2:28:47 AM7/13/16
to JaCoCo and EclEmma Users
On Tuesday, July 12, 2016 at 4:55:35 PM UTC+2, Marc R. Hoffmann wrote:
> the aggregator project does not work as a container for the coverage
> report, unfortunatelly it is build *before* its modules. Therefore the
> report is empty. You need a separate project which the projects under
> test do not depend on:

The whole idea of the aggregator project is that it builds *after* the modules. This is also how it seems to work: The build starts with the parent pom, then module a and b get built, and lastly the aggregator pom is built. So I'm not sure that your idea will solve the issue. Also, before I separated the aggregator and parent pom, I tried moving all the site stuff in a separate module (something akin to the report module in your example), that didn't work. The (huge) downside to this approach is also that I have to specify the dependencies twice. So, again, why can't it work from the aggregator module? Other aggregate reports work fine, and the execution order is fine as well. Especially since I usually do a mvn install first, and only then I do a mvn site. This means that even if the order is wrong, execution data is available when I run mvn site!

Regards,

Michel.

Bernd Winter

unread,
Jul 13, 2016, 5:54:26 AM7/13/16
to JaCoCo and EclEmma Users
As I have been fighting with that issue of an aggregate POM not being able to generate an aggregated coverage report over all listed modules exactly as Michel, I still want to make sure I understood the mechanism correctly:

The goal report-aggregate does not work like this (when running e.g. mvn clean test site on the aggregate POM):
  • each mentioned module in the <modules> is run first, also generating all jacoco.execs
  • afterwards the aggregate module runs its own configured reports (including jacoco:report-aggregate), generating and merging all coverage reports from the <modules>

Intuitively, I would have expected the mechanism to work like that. Instead, I think you're emphasizing that the general Maven concept of aggregator POMs works differently and is not capable of realizing that "ideal" scenario. Seems that the Maven aggregator POM is just good for listing and running a couple of modules with one call and not for final result collection... Am I right so far?


So how would you configure a separate report module like you mentioned? The most important piece of information is obviously that the report-aggregate goal does not use the <modules> list to gather coverage information from but rather the <dependencies> list, right? So basically we would set up a module with lots of "fake" dependencies?


That's what I thought would work at first ("report-aggregate" and "aggregation POM" sounds like it just fits together... maybe the jacoco-goal should better be "report-collection" or something to avoid potential mixup...) but is obviously wrong:


<project ...>

 
<groupId>org.acme</groupId>
 
<artifactId>report-module</artifactId>
 
<version>1.0</version>
 
<packaging>pom</packaging>

 
<modules>
   
<module>../module-a</module>
   
<module>../module-b</module>
 
</modules>

 
<build>
   
<plugins>
     
<plugin>
       
<groupId>org.jacoco</groupId>
       
<artifactId>jacoco-maven-plugin</artifactId>
       
<version>0.7.7.201606060606</version>
       
<executions>
         
<execution>
           
<id>jacoco-initialize</id>
           
<goals>
             
<goal>prepare-agent</goal>
           
</goals>
         
</execution>
         
<execution>
           
<id>jacoco-site-aggregate</id>
           
<phase>prepare-package</phase>
           
<goals>
             
<goal>report-aggregate</goal>
           
</goals>
         
</execution>
       
</executions>
     
</plugin>
   
</plugins>
 
</build>
</project>

Is this the way to go then?


<project ...>

 
<groupId>org.acme</groupId>
 
<artifactId>report-module</artifactId>
 
<version>1.0</version>
 
<packaging>jar</packaging> <!-- instead of the aggregate 'pom' a default module? -->

 
<dependencies>
   
<dependency>
     
<groupId>org.acme</groupId>
     
<artifactId>module-a</artifactId>
   
</dependency>
   
<dependency>
     
<groupId>org.acme</groupId>
     
<artifactId>module-b</artifactId>
   
</dependency>
 
</dependencies>

 
<build>
   
<plugins>
     
<plugin>
       
<groupId>org.jacoco</groupId>
       
<artifactId>jacoco-maven-plugin</artifactId>
       
<version>0.7.7.201606060606</version>
       
<executions>
         
<execution>
           
<id>jacoco-initialize</id>
           
<goals>
             
<goal>prepare-agent</goal>
           
</goals>
         
</execution>
         
<execution>
           
<id>jacoco-site-aggregate</id>
           
<phase>prepare-package</phase>
           
<goals>
             
<goal>report-aggregate</goal>
           
</goals>
         
</execution>
       
</executions>
     
</plugin>
   
</plugins>
 
</build>
</project>


Marc Hoffmann

unread,
Jul 13, 2016, 8:29:06 AM7/13/16
to jac...@googlegroups.com
Hi,

your observations are correct. This the way how Maven works. Any goal in
the aggregator project is executed *before* its modules therefore we
cannot create a report here. Different Maven plugin use different
workarounds here, we decided for a solution which follows the Maven
semantics.

Your observation about report-aggregate is also correct, see goal
documentation for details:
http://www.eclemma.org/jacoco/trunk/doc/report-aggregate-mojo.html

Our integration tests contain a example project:
https://github.com/jacoco/jacoco/tree/master/jacoco-maven-plugin.test/it/it-report-aggregate

Regards,
-marc




On 2016-07-13 11:54, Bernd Winter wrote:
> As I have been fighting with that issue of an aggregate POM not being
> able to generate an aggregated coverage report over all listed modules
> exactly as Michel, I still want to make sure I understood the
> mechanism correctly:
>
> The goal report-aggregate does NOT work like this (when running e.g.
> mvn clean test site on the aggregate POM):
>
> * each mentioned module in the <modules> is run first, also
> generating all jacoco.execs
> * afterwards the aggregate module runs its own configured reports
> (including jacoco:report-aggregate), generating and merging all
> coverage reports from the <modules>
>
> Intuitively, I would have expected the mechanism to work like that.
> Instead, I think you're emphasizing that the general Maven concept of
> aggregator POMs works differently and is not capable of realizing that
> "ideal" scenario. Seems that the Maven aggregator POM is just good for
> listing and running a couple of modules with one call and not for
> final result collection... Am I right so far?
>
> So how would you configure a separate report module like you
> mentioned? The most important piece of information is obviously that
> the report-aggregate goal does NOT use the <modules> list to gather
> coverage information from but rather the <dependencies> list, right?
> So basically we would set up a module with lots of "fake"
> dependencies?
>
> That's what I thought would work at first ("report-aggregate" and
> "aggregation POM" sounds like it just fits together... maybe the
> jacoco-goal should better be "report-collection" or something to avoid
> potential mixup...) but is obviously WRONG:
> Is this the WAY TO GO then?
> --
> 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 jacoco+un...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jacoco/afa8578d-cb48-452b-88ae-1578a965d117%40googlegroups.com
> [1].
> For more options, visit https://groups.google.com/d/optout.
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/jacoco/afa8578d-cb48-452b-88ae-1578a965d117%40googlegroups.com?utm_medium=email&utm_source=footer

Marc Hoffmann

unread,
Jul 13, 2016, 8:36:14 AM7/13/16
to jac...@googlegroups.com
Hi Michel,

> The whole idea of the aggregator project is that it builds *after* the
> modules.

Yep, that would be nice. Unfortunatelly this is not how Maven works.
There are different known workarounds like you proposed to run thne
build with two Maven invocations:

mvn install
mvn site

Unfortunatelly these workarounds all come with drawbackes. We wanted to
build JaCoCo itself in one run, therefore we decided against this
solution.

Please find a detailed discussion of the design options here:
https://github.com/jacoco/jacoco/wiki/MavenMultiModule


Regards,
-marc

Bernd Winter

unread,
Jul 13, 2016, 9:31:27 AM7/13/16
to JaCoCo and EclEmma Users
Hi Marc,
thanks for the clarification!


On Wednesday, 13 July 2016 14:29:06 UTC+2, Marc R. Hoffmann wrote:
Your observation about report-aggregate is also correct, see goal
documentation for details:
http://www.eclemma.org/jacoco/trunk/doc/report-aggregate-mojo.html

Yes, I read that piece of documentation several times, but I did not realize that
The report is created from all modules this project depends on. 
literally means that the modules have to be listed in <dependencies>. Because I had that aggregation module already in mind, it sounded to me that the code-coverage-tested modules listed in <modules> would be the right way to show the "dependency".
 

That is indeed a great example. I did not find that one before or pay it enough attention. That should be referenced in the goal documentation! It really lacks an unambiguous and clear example for aggregation in the documentation (either goal doc. or usage page (http://www.eclemma.org/jacoco/trunk/doc/maven.html))...
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages