What about Luke's suggestion (last comment at http://forums.gradle.org/gradle/topics/jacocoreport_tasks_dont_have_dependencies_on_tasks_that_produce_coverage_data) to finalize test task with jacoco task? Then you would always get a coverage report whenever test is being run and jacoco plugin is applied.
On Wed, Nov 20, 2013 at 3:26 PM, Szczepan Faber < szczepan.fa...@gradleware.com> wrote: > Thanks Andrew, this helps a lot. > > Jacoco report task that is introduced by our plugin is coupled with a > particular test task. There's no use case I can think of running the jacoco > report without running this test task before. Effectively, the user needs > to always include this particular test task explicitly at the command line, > which is kind of awkward (and surprising for new users). I'd like to change > this sometime this week and replace mustRunAfter with dependsOn. I'll do it > unless someone replies with a good story that supports mustRunAfter ;) > > @Rene, can you comment on the use of relative paths? E.g. what's the > intention? > > @Andrew, I forgot to say my thanks for the contribution. The experience is > so much better than with the coverage plugins I used in the past. > > Cheers! > > > On Wed, Nov 20, 2013 at 3:32 PM, <andrew.obers...@securian.com> wrote: > >> 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://forums.gradle.org/gradle/topics/jacocoreport_tasks_dont_have_dependencies_on_tasks_that_produce_coverage_data> >> *http://issues.gradle.org/browse/GRADLE-2764*<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/commits/master/subprojects/jacoco/src/main/groovy/org/gradle/testing/jacoco/plugins/JacocoTaskExtension.groovy> >> *https://github.com/gradle/gradle/pull/138*<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 >> > > > > -- > Szczepan Faber > Principal engineer@gradle; Founder@mockito >
