[GRADLE-2955] gradle jacoco plugin shows excluded packages with 0% coverage Created: 18/Nov/13  Updated: 16/Jan/17  Resolved: 16/Jan/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Fixed Votes: 19


 Description   

If I exclude a package from coverage reporting via

test {

jacoco

{ excludes = ["com.blah.*"] }

}

it is excluded in the jacoco runtime but not in the report generation.
this results in the package having 0% coverage in the jacoco report



 Comments   
Comment by Gradle Forums [ 18/Nov/13 ]

Any chance of getting a complete sample we can use to create a fix?

Comment by Gradle Forums [ 18/Nov/13 ]

You can see it in the java quickstart example if you add:

test.jacoco.excludes << "*Person"

I made a quick example in github [1]https://github.com/frankiesardo/jacoc...
As you see if you ignore a file the test coverage drops to 50% instead of being 100%
----------------------------------------------------------------------------------------
[1] https://github.com/frankiesardo/jacoco-example

Comment by Paul Doran [ 04/Dec/13 ]

Is there a timeline for a fix on this? I've just encountered the bug too.

If someone can point me in the right direction then I'm more than happy to attempt a fix myself.

Comment by Thibault Kruse [ 13/Jan/14 ]

+1, having the same problem

Comment by David Isaman [ 17/Jan/14 ]

+1, having the same problem

Comment by Wolfgang Schmiesing [ 24/Jan/14 ]

As far as I can see Gradle internally uses Jacoco ANT tasks. "test.jacoco.excludes" is only used for coverage analysis not for report generation.
See http://stackoverflow.com/questions/14404790/jacoco-not-excluding-classes-when-using-ant for a solution of this problem using ANT tasks.
I think porting the above solution to the Gradle Jacoco plugin should fix the issue.

Comment by Eric Nichols [ 25/Feb/14 ]

+1, have not yet figured out how to make excludes work properly.

Comment by David Isaman [ 26/Feb/14 ]

For those that are using a combination of Gradle, Jacoco, and Sonar: there is a setting in Sonar that will allow you to exclude files/directories. In Sonar results, if you go to Configuration->Settings->Exclusions->Coverage Exclusions, you can set the list of directories to exclude. We have not found a way around this issue with just Gradle and Jacoco.

Comment by Hari Samala [ 24/Apr/14 ]

The excludes option is available only for the test.jacoco task and not for jacocoTestReport. Instead you can define the classDirectories but filter the generated sources as shown below:

def generatedSources = ['com/yahoo/**', 'com/amazon/**']

test {
     jacoco {
          excludes = generatedSources
     }
}

jacocoTestReport {
     doFirst {
          classDirectories = fileTree(dir: "${buildDir}/classes/main/").exclude(generatedSources)
     }
     reports {
          xml.enabled true
     }
}

Comment by Jeff Jones [ 07/May/14 ]

Hari,
I tried your solution and it does remove the excluded items from the report but it does not create the source highlighting. The most detail I can get is the class name I cannot click on it to view the code.

Comment by Hari Samala [ 07/May/14 ]

Hi Jeff, The jacocoTestReport task does not run by default when you run 'gradle build'. You need to run it explicitly. Try running gradle clean build jacocoTestReport

I am using gradle 1.10 and I am able to generate the report with source code highlighting.

Comment by Jeff Jones [ 07/May/14 ]

I am on gradle 1.11 and I am running the jacocoTestReport task. My project contains sub projects and all of our tests are under one of these sub projects. The test sub project depends on all of the other ones. Here is the code I added to my gradle script to add all of the classesDir's from all of the sub projects to the jacoco report.

jacocoTestReport {
    doFirst {
        rootProject.subprojects.each {
            if (new File("${it.sourceSets.main.output.classesDir}").exists()) {
                logger.debug("Class files: ${it.sourceSets.main.output.classesDir}")
                if (classDirectories == null) {
                    classDirectories = fileTree(dir: "${it.sourceSets.main.output.classesDir}", includes: jacocoIncludes, excludes: jacocoExcludes)
                } else {
                    classDirectories += fileTree(dir: "${it.sourceSets.main.output.classesDir}", includes: jacocoIncludes, excludes: jacocoExcludes)
                }
            }
        }
    }
    reports {
        //xml.enabled true
    }
}  
Comment by Tuncay Senturk [ 24/Jun/14 ]

Hi,

As far as I understood, excluding sources (using jacocoTestReport task as Hari said) works fine for csv, xml, or html reports.

On the other hand, if you use Jenkins and want to publish your coverage results to CI server and use coverage ratio to break the build, you need to produce .exec files which are populated by test.jacoco task.

But, if we use excludes = generatedSources within this task, we face the problem of showing as 0% coverage for the excluded classes.

This is really annoying. Do you have any plan to fix this?

Tuncay Senturk

Comment by Mirth Fal [ 30/Sep/14 ]

Hi Tuncay, I'm able to get correct code coverage on Jenkins using the JaCoCo plugin. The trick is that `jacocoTestReport` produces `.ec` files, not `.exec`. In the field for "path to exec files", putting "*/*.ec" works. Then, using the inclusion and exclusion fields, I was able to exclude the files that I didn't want code coverage for.

I'm still not able to get correct code coverage running from the command line (gradle wrapper), but at least Jenkins reports the correct thing now.

Comment by Yannick Welsch [ 21/Feb/15 ]

The solution for Ant mentioned above by Wolfgang Schmiesing also works for Gradle. The solution is to provide the classDirectories under the form of a FileTree object with the desired includes/excludes. Gradle then does the necessary conversion when invoking the Ant task.

An automated conversion can be done using the following code. It converts the classDirectories to provide FileTree objects instead of File objects representing folders to the jacocoTestReport task.

jacocoTestReport {
    afterEvaluate {
        classDirectories = files(classDirectories.files.collect {
            fileTree(dir: it, exclude: 'com/blah/**')
        })
    }
}
Comment by Jared Burrows [ 25/Apr/15 ]

Thank you Yannick Welsch! That works very well!

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Sol Mumey [ 16/Nov/16 ]

Thanks, Yannick Welsch! For a multi-project build with Jacoco configuration in a subprojects afterEvaluate block of the root build.gradle, a second afterEvaluate block did not work; instead I used a doFirst block:

			jacocoTestReport {
				doFirst {
					try {
						classDirectories = files(classDirectories.files.collect {
							fileTree(dir: it, exclude: subproject.property('jacoco.excludePatterns'))
						})
					} catch (e) {
						println "jacoco: no exclusion patterns due to ${e.message}"
					}
				}
			}
Comment by Benjamin Muschko [ 16/Jan/17 ]

It doesn't look like there's an issue to me. Users are seeing this either because of the fact that

1) jacocoTestReport does not define a task dependency on test.
2) build script logic wasn't evaluated at the right time based on given logic.

Please open an issue on GitHub if you still think that there is an issue.

Generated at Wed Jun 30 12:35:55 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.