Is this patch going to be implemented in Jacoco release soon? A lot of us desperately need this aggregate report feature for multi-module builds. Much appreciated for this patch keep up the great work!

Report looks good, but the 'check' goal does not seem to count coverage from all modules. Is there an example of how to configure it? I am testing here: https://github.com/lhazlewood/mvn-multi-module-web-with-jacoco-it

@vydra Thanks for the feedback. Yes it does look like there is an issue with the check goal. Since I was purely looking at reporting I didn't look at this. But there seems like no reason why the same approach can't be used for check too.

I had a quick go with you project and producing the aggregate jacoco.exec worked by invoking the aggregate-report goal. Then I ran check after disabling the code that causes check to explicitly refuse to run over pom type projects. It seemed like it worked however it returned success despite obviously failing the requirements, so something is not right.

I will take a look and will keep you/this pull request updated on any improvements.

Sounds great!

On Wed, May 22, 2013 at 1:10 PM, John Oliver notifications@github.comwrote:

@vydra https://github.com/vydra Thanks for the feedback. Yes it does
look like there is an issue with the check goal. Since I was purely looking
at reporting I didn't look at this. But there seems like no reason why the
same approach can't be used for check too.

I had a quick go with you project and producing the aggregate jacoco.exec
worked by invoking the aggregate-report goal. Then I ran check after
disabling the code that causes check to explicitly refuse to run over pom
type projects. It seemed like it worked however it returned success despite
obviously failing the requirements, so something is not right.

I will take a look and will keep you/this pull request updated on any
improvements.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/97#issuecomment-18304557
.

http://www.linkedin.com/in/dvydra
http://www.testdriven.com
http://twitter.com/vydra

@vydra I have updated to include the check goal.

See how I configured it at:

https://github.com/johnoliver/mvn-multi-module-web-with-jacoco-it/

running the following seemed to work fine

mvn clean package org.jacoco:jacoco-maven-plugin:0.6.3-SNAPSHOT:aggregate-report org.jacoco:jacoco-maven-plugin:0.6.3-SNAPSHOT:check

There are a few problem with this at the moment, first is that aggregate-report is needed to be run as this is what is doing the aggregation. If people feel it is likely that people will want the check functionality independent of the report then I can look at refactoring out the aggregation part to share between the two goals.

Second is that the aggregation has to be specified as a goal rather than bound to a lifecycle in the pom. This is since if it gets executed as part of a lifecycle the aggregation will be executed before the reactor projects, thus aggregating nothing. It is possible there may be work arounds for this such as the process described in: http://blog.sonatype.com/people/2009/05/how-to-make-a-plugin-run-once-during-a-build/

Otherwise let me know if this works.

My most needed feature. It would be good to have both transitive coverage and project-only coverage, but if I had the choice of only one, it would be transitive.

Its been 6 months, any update or resolution for this feature?

Given that the maven merge goal was accepted recently but is not yet released (See https://github.com/jacoco/jacoco/blob/master/jacoco-maven-plugin/src/org/jacoco/maven/MergeMojo.java). My guess is this pull request will not be accepted as there is a significant amount of overlap with that Mojo. I am not sure with the merge mojo if there is an intended way of going full cycle from module coverage-> merged exec file -> aggregate-report or if that is going to require an additional mojo on top. My guess is it will require multiple calls to maven i.e:

mvn test
mvn jacoco:merge
mvn report -DdataFile=./jacoco.exec

Using merge does not address the issue of cross module coverage, only producing an aggregated report but now that code exists it should be reused here when producing cross module coverage too.

Again I am willing to do the work to update this pull request to reuse the code from the merge goal, but there seems to have been little enthusiasm for merging this pull request in general.

This is a desperately needed feature that other code coverage tools like Clover have. I really hope they re-consider and add this pull request.

I would also ask either for this to be merged or for instructions how to achieve equivalent functionality with existing maven plugin. We currently maintain a fork of JaCoCo with this patch applied but would rather use the official releases.

@johnoliver et al.: I try to describe the usecase:

• Given
  • I have a multi-module Maven project with a root-POM and
  • I have specified jacoco:aggregate-report on root-POM level to be run during phase verify
• When
  • I execute mvn clean verify on root-POM level
• Then
  • I expect all tests and integration tests to be run firstly in the single modules 1-N collecting their individual coverage in their respective ${reactorbase}/module[1-N]/target/jacoco.exec and reports to be generated in ${reactorbase}/module[1-N]/target/site/jacoco/ and
  • I expect an aggregated report in ${reactorbase}/target/site/jacoco and
  • I expect the check goal (check-aggregate?) to check the overall coverage.

Is this the usecase?

Since jacoco-0.6.4 you may differentiate between coverage coming from unit and integration tests, see prepare-agent-integration and report-integration.
Should these be integrated as well?

Sample how to achieve run when the last module hits aggregate-report: install:install will delay installation until the last reactor project reaches install phase.

This is part of the use case, which is the merging of multiple reports into one aggregated report, however I believe you have already addressed this issue partially with the MergeMojo but as I said before I am unsure if you need an extra step to then report on the merged exec file.

But the additional use case that is very critical, is counting coverage from tests that are outside of the module that a class is defined. As I mentioned in the original description if a test in module A covers code in module B, I want the report to count those lines in module B as covered. Currently (or at least at the time this pull request was made), jacoco would only report on code that was inside the same module as the test.

Again I am willing to update this pull request to reuse the MergeMojo to prevent duplicated functionality, provided it is accepted that this is a use case you want to cover and are willing to merge an acceptable pull request on the matter. Given the number of people that have requested this feature it seems like one that should be addressed.

Some random thoughts:

• JaCoCo build itself is a possible example for a aggregate report
• We might need includemudules/excludemodules properties to specify the projects which should be aggregated. Especially in the case where test code is in different module one would probably not expect the test code in the report.
• Instead of defining a new goal we might configure the existing report goal.

+1 ... we would like to see this as well. We are currently aggregating in Sonarqube, but our developers don't want to have to publish to Sonar in order to see the aggregate coverage on the their multi-module projects, and we also publish our sites and that's the one missing report at the top level for those. Why has John's pull request been sitting open for so long? We left Cobertura because it was starting to feel like a dead project ... and now this.

WORKAROUND

Put this in your build.gradle after your project and allProjects declarations:

/*
 * This is roughly based upon this post:
 * https://discuss.gradle.org/t/merge-jacoco-coverage-reports-for-multiproject-setups/12100/6
 */
task jacocoRootReport(type: JacocoReport, group: 'Coverage reports') {
    description = 'Generates an aggregate report from all subprojects'
    dependsOn(subprojects.test)

    additionalSourceDirs = files(subprojects.sourceSets.main.allSource.srcDirs)
    sourceDirectories = files(subprojects.sourceSets.main.allSource.srcDirs)
    classDirectories = files(subprojects.sourceSets.main.output)
    executionData = files(subprojects.jacocoTestReport.executionData)

    reports {
        html.enabled = true
        xml.enabled = true
    }

    doFirst {
        executionData = files(executionData.findAll { it.exists() })
    }
}
check.dependsOn jacocoRootReport

Would be really good to have this feature. As a workaround, I'm currently using a groovy script with the GMaven plugin (groovy-maven-plugin:execute). The script is executed from a separate 'aggregate' module and combines coverage data for all projects that are part of the reactor build: https://gist.github.com/ksperling/57b81ea723e319967d24

+1

This feature is badly needed.

+1

+1

I'm disappointed that there are so many +1's on this PR yet it appears there is no progress. What do we need to do to get this going forward?

+1

Not sure why this is not merged yet.

+1

For those interested I have updated the pull request to have merged with the latest 0.7.7-SNAPSHOT. So if you are using this patch you can upgrade to the latest version.

@johnoliver Can you please let me know how to generate this without ant support?

It looks as maven plugin is stuck for few years on simple problem. Do not get me wrong. I appreciate your work. Especialy "johnoliver" who tries to merge this feature. But in the meantime people are migrating to gradle which is growing faster. In example look at this link:
https://gist.github.com/aalmiray/e6f54aa4b3803be0bcac
Gradle users are solving problems in days instead of years.

+1 for merging this feature.

+1

Dear god, people, please, stop using +1.
There's a new reaction system for that sort of thing.

This request is so ancient (nevertheless important) that it doesn't deserve such a modern reaction system. The solution is to fix the issue, not to make the +1 less painful.

@johnoliver @Godin @mfriedenhagen
I finally found some time to dive into this issue and did a detailed analysis of the issue together with @jwloka. We discussed different solutions and finally implemented a different approach in PR #388.

Fixed with #388.