Some related discussions for your 1st and 3rd points. http://forums.gradle.org/gradle/topics/jacocoreport_tasks_dont_have_dependencies_on_tasks_that_produce_coverage_data
http://issues.gradle.org/browse/GRADLE-2764 You can see some stuff in the history of JacocoTaskExtension related to #2. There were some issues with some of the tests failing as noted in my original pull request. https://github.com/gradle/gradle/commits/master/subprojects/jacoco/src/main/groovy/org/gradle/testing/jacoco/plugins/JacocoTaskExtension.groovy https://github.com/gradle/gradle/pull/138 The doFirst was to make the evaluation of the arguments lazy. Could be a better way, but that's all I thought of at the time. Andrew Oberstar Szczepan Faber <szczepan.fa...@gradleware.com> wrote on 11/20/2013 08:19:48 AM: > From: Szczepan Faber <szczepan.fa...@gradleware.com> > To: dev@gradle.codehaus.org, > Date: 11/20/2013 08:19 AM > Subject: [gradle-dev] jacoco questions > > Hey, > > I have a couple of questions re jacoco: > > - jacoco tasks don't depend on test tasks. So running 'jacoco' has > no effect (task is skipped). Is this intentional? I think jacoco > report task should depend on test task that produces the input. > > - the agent arguments use relative paths. What is the reason of > using relative paths? Is it to conserve the length of the args? If > absolute paths are used, it's easier to hook up jacoco for e2e > integration tests (e.g. container needs to start with agent > settings) because the getAsJvmArgs() method can be used to build > agent arguments. > > - some html reports allow to navigate to the class level and > inspect the class visually, by looking at decorated source file. > However some classes are not decorated - e.g. I can only see the > tabular view of the coverage, but cannot drill down to the decorated > source file. I haven't figured out the pattern of when it works or > not. Anyone knows about this issue? > > - I've noticed that doFirst() is used to configure test tasks' > jvmargs. Currently, the up-to-date checks don't work reliably when > task inputs or outputs are changed during this task execution. > > Cheers! > -- > Szczepan Faber > Principal engineer@gradle; Founder@mockito
