> The execution order is defined when the output-input characteristic requires > it. > > > I'm probably not familiar enough with gradle to know exactly what you mean by > 'output-input characteristic' > could you elaborate further
Gradle tasks can define what they take as input and what they produce as output. And many tasks do. If task x produces an output artifact that is consumed as input by task y then a dependency on both x and y is guaranteed to be in executed sequence: first x, second y (unless the output is up to date and x can be skipped). x -> artifact -> y a.dependsOn = [y, x] // declare the 'what', not the 'how' This behavior is one of the distinctively mindful design choices of Gradle. Imagine the sequence of dependsOn declarations would define the order. You can get a conflict with the output-input chain sequence. Now - who wins? That in my opinion is the best example where imposing an order-by-declaration-sequence limits the build system. It is not the main reason, though. The reason - on an architectural level - is that dependencies _have_ no order by nature. Also, with an imposed order, you would care too much about the "how" where you should rather care about than the "what". cheers Dierk P.S. dependency-order-by-declaration-sequence is in my eyes one of the features that makes so many ANT builds difficult to maintain. You need to know the whole build to safely make a tiny change in the dependency chain and you have to make those changes more often. You even have to know the whole build to _use_ it correctly! P.P.S. In case you haven't guessed, yet: I love Gradle! Kudos to Hans and Adam!
