On 11 March 2013 09:34, Marcin Erdmann <[email protected]> wrote:
> Thanks for taking care of Szczepan's email, Adam. I'm in Italy for a week > with friends and have only limited access to the net and only using my > phone so I really aprecciate that. Your responses to Szczepan's questions > were as if I wrote them. Good to know that we're on the same page regarding > this stuff. > > Marcin > > P.s. Should I add some more docs about this when I'm back? Looks to me > like questions like that might be asked by a Gradle user as well... > That would be excellent. Thanks. Are you still interested in continuing on with the reporting work? There are a few ways we could go with it: - Some more work on the task execution model, to allow 'finaliser' tasks. We'd use this to automatically run the dashboard task whenever a reporting task is executed, and to split reporting out of the test task. We also have a pull request queued up to add a jacoco plugin (thanks to Andrew Oberstar) which would also make use of this. - Retrofit some existing reports so that they end up in the dashboard, in particular, the test reports. There are some other reports that could be included, like the build comparison report, the (text) project reports and the profile report. - Add more html reports, for checkstyle and the project reports and include these in the dashboard. - Start including documentation as well as reports in the dashboard. Any preferences? Other stuff you'd like to work on? Not interested at all? Personally, I would love to see some more work on task execution model, if you're interested in working on it. > On Mar 10, 2013 9:29 PM, "Adam Murdoch" <[email protected]> > wrote: > >> >> >> >> On 11 March 2013 03:24, Szczepan Faber <[email protected]>wrote: >> >>> Hey Marcin, >>> >>> Dzieki for this awesome code ;) >>> >>> I have some questions about how it works. I know I could probably figure >>> out this from the code/spec but it might be useful for others (plus I >>> didn't see that documented in the docs for the new api methods). >>> >>> Say I configure: >>> foo.mustRunAfter(bar) >>> >>> 1. When I run 'gradle bar' and 'bar' succeeds, does gradle execute 'foo'? >>> >> >> No. The rule only takes effect if both foo and bar are in the task graph. >> There will be another rule that we add to allow you to force tasks to be >> added to the graph - eg if the unit tests run, then also run the test >> report task. >> >> >>> 2. When I run 'gradle bar' and 'bar' fails, does gradle execute 'foo'? >>> >> >> No. As above. If you run 'gradle bar foo' and 'bar' fails, 'foo' will >> still be executed (if you're running with --continue). It's an ordering >> rule not a dependency rule. >> >> >>> 3. When I run 'gradle foo bar', what's the order of execution? >>> >> >> bar and all its dependencies, then foo and all its remaining dependencies. >> >> >>> 4. When bar.dependsOn foo and I run 'gradle bar', what's the order of >>> execution? >>> >> >> You'll get an exception, as you've got an ordering cycle. The 'must' in >> the name means that it is a mandatory ordering, and so it blows up when >> there are contradictory rules. We'll probably add an equivalent 'should' >> ordering too - my unit tests should run before my int tests, but it doesn't >> matter if they don't. >> >> >>> 5. Is mustRunAfter behavior also respected in an incubating parallel >>> build? Probably not, but just checking :) >>> >> >> It is. The 'is this task ready to execute' logic takes ordering rules >> into account. >> >> >> -- >> Adam Murdoch >> Gradle Co-founder >> http://www.gradle.org >> VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting >> http://www.gradleware.com >> >> Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: >> http://www.gradlesummit.com >> > -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
