On 11/04/2013, at 11:36 PM, Szczepan Faber <szczepan.fa...@gradleware.com> 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
