On 12 April 2013 03:20, Peter Niederwieser <pnied...@gmail.com> wrote: > I agree with Luke. The guarantees have to be the same whether or not > `--parallel` is used. If necessary, a new command line syntax/switch could > be introduced that doesn't take ordering of task names into account (though > I'm not sure it's needed). Changing the guarantees of the current syntax is > not an option in my mind. Maybe build types could offer ways to control > parallel execution constraints.
If we want to provide a guarantee of task ordering from the command line, then we should enforce it. Currently, I don't believe any such guarantee is in place. Certainly "gradle X Y" does not state "Y mustRunAfter X", because if "X dependsOn Y" then Y will run _before_ X. If you actually express: X.dependsOn(Y) Y.mustRunAfter(X) you get a circular dependency exception. So the current command-line ordering is more like "should run after". I would prefer we stick with this model. In multiproject world it's a bit more complicated, though: for "gradle X Y" in a multiproject, is it true that "*:Y should run after *:X"? The alternatives I see are: - Must run after: I don't think this is an option as it would cause circular dependency exceptions where there now are none. - Should run after: When combined with --parallel, this doesn't provide the ordering 'guarantee' that is currently perceived. But when combined with more expressive ordering rules (build types?) I think it would work well. - "really, really, should run after": almost as strong as must-run-after but yielding in the face of dependencies. (I'm not really serious about this). - Run all of "X", then run all of "Y" with the current project state: that's probably more like what users expect. My issue with this guarantee is that it would prevent certain parallel optimisations, when all you want to do is run 2 independent tasks: "gradle :a:build :b:build". (nb: Prior to "mustRunAfter", this was pretty much what we did for non-parallel builds. Now if "X.mustRunAfter(Y)" then 'gradle X Y' will result in Y,X. So Y isn't really executed independently of X.) I prefer to think of "gradle X Y" as "run both X & Y, and Y should run after X". Any strict ordering rules should be encoded in the build. ciao Daz > > Cheers, > Peter > > > Luke Daley-2 wrote >> On 11/04/2013, at 11:36 PM, Szczepan Faber < > >> szczepan.faber@ > >> > wrote: >> >>> Hey guys, >>> >>> Today, I had a long chat with PeterN about our current strategy for >>> command line order in a parallel build. Consider this: >>> >>> gradle taskA taskB --parallel >>> >>> 1. We can let taskA graph and taskB graph execute in parallel. That's how >>> Gradle 1.5 works and it feels pretty natural to me. It breaks certain >>> 'clean build' scenarios (e.g. >>> http://forums.gradle.org/gradle/topics/problem_with_clean_in_parallel_mode) >>> 2. We can let taskA graph execute in parallel first. Then we let the >>> taskB graph execute in parallel. This approach can be considered more >>> consistent with the single threaded execution. >>> >>> What's the right way? >> >> Given what we have right now, it has to be that these can't be run in >> parallel (option 2). That is, 'taskB' must-run-after 'taskA'. My reasoning >> for this is that this is the only execution order control mechanism >> outside of dependencies, so this seems the safest option. >> >> If I run: ./gradlew build release >> >> I expect that things are built and tested before any releasing occurs. >> Release tasks rarely have hard dependencies on test tasks. >> >> It's far less clear to me one there is richer information available. If >> there are all kinds of mustRunBefore etc. relationships defined between >> tasks, then you could make an argument that Gradle should parallelise as >> much as possible and just respect the relationships as defined. My gut >> feel though is that task order on the command line should _still_ imply a >> must-run-after relationship though as it's more predictable and easier to >> understand. >> >> -- >> Luke Daley >> Principal Engineer, Gradleware >> http://gradleware.com >> >> Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: >> http://www.gradlesummit.com >> >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email > > > > > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/command-line-order-and-parallel-build-tp5711162p5711165.html > Sent from the gradle-dev mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
