The only issue I can see with finalizing is that you don't always need the report, e.g. if I'm pushing the data into Sonar. However, this would be the same behavior as the test reports, so there could be value in consistency.
Andrew Oberstar Marcin Erdmann <marcin.erdm...@proxerd.pl> wrote on 11/20/2013 10:30:00 AM: > From: Marcin Erdmann <marcin.erdm...@proxerd.pl> > To: dev@gradle.codehaus.org, > Date: 11/20/2013 10:30 AM > Subject: Re: [gradle-dev] jacoco questions > > 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 theintention? > > @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://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 > > > -- > Szczepan Faber > Principal engineer@gradle; Founder@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
