JacocoReport should not require `destination` to be set for disabled reports

Old Forum Archive Bugs
1

I have a custom JacocoReport task in my project. I set reports.xml.enabled = false and reports.csv.enabled = false because I only care for the html report. When I run the task with Gradle 3.0, it complains that

Some problems were found with the configuration of task ‘:combinedJacocoReport’.

No value has been specified for property ‘reports.xml.destination’.
No value has been specified for property ‘reports.csv.destination’.

This did not happen with Gradle 2.14.1.

2

Hi Jochen,

I cannot reproduce this problem with the standard JaCoCo task.

Can you share details about your customisation such that I can reproduce the problem?

We also increased the default JaCoCo version to 0.7.7.201606060606. You can also check if setting it manually to another version (in previous Gradle versions it was 0.7.6.201602180812) solves the issue.

3

Changing the Jacoco dependency version has no effect. And that makes sense, because the error comes out of Gradle.
The project in question is Apache Tapestry 5 (https://github.com/apache/tapestry-5/) and the failing task is combinedJacocoReport https://github.com/apache/tapestry-5/blob/master/build.gradle#L389. See https://travis-ci.org/apache/tapestry-5/builds/159242941 for the failed build.

4

Hi Jochen,

It seems that this (misleading) error originates from the fact that there are no conventions applied by the JaCoCo Plugin. In fact, there should always be a ‘destination’ for each report type, because there is a default one.

In your case, the JaCoCo plugin is not applied to the root project and therefore the application of conventions is not triggered. The problem is not reported in 2.14.1 because the validation was added in 3.0.

If you add apply plugin: "jacoco" or move the exiting one from subprojects to allprojects it works.

1 Like
5

Thanks for the hint. However, I think that the validation should not require that a destination be set for a disabled report.

6

@jendrik I agree with @jochenberger on this one. There are multiple cases when the JacocoReport task can be used without having the plugin applied to the project.

Two examples we’re using in our project:

  • We dump code coverage from the remote machine and then use JacocoReport to merge severals dumps into one html report

  • We manually merge an overall report from a bunch of disjoint unit test execution reports

To me it seems that validating that report destinations are provided only makes sense in case the plugin was applied to the project, not in the case when JacocoReport is used as a standalone task with a custom configuration. The only thing to validate in this case would be that at least one report type is configured.

Compare 2.14 configuration

ext.coverageReportOptions = { task ->
    deliveredSubprojects.each {pr ->
        task.sourceSets pr.sourceSets.main
    }
    jacocoClasspath = configurations.jacocoAnt
    reports {
        html.enabled = true
        html.destination = task.reportDestination
    }
}

with 3.0 configuration

ext.coverageReportOptions = { task ->
    deliveredSubprojects.each {pr ->
        task.sourceSets pr.sourceSets.main
    }
    jacocoClasspath = configurations.jacocoAnt
    reports {
        html {
            enabled true
            destination task.reportDestination
        }
        xml { //ignored
            enabled false
            destination task.reportDestination + '_xml'
        }
        csv { //ignored 
            enabled false
            destination task.reportDestination + '_csv'
        }
}