On 21 Nov 2013, at 5:54 am, andrew.obers...@securian.com wrote: > 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.
I would solve this by introducing test suites as a first class concept, then we can provide a bunch of different kinds of test outputs in various combinations for a given suite of tests. This would allow different tasks to run based on what you’re asking for. For now, however, we’re stuck with a single task as the test suite definition, and we have to choose something that’s going to fit most people’s use cases but probably not everyone’s use cases. > > > 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 > > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
