Paul, thanks for your response. My comments below.
On Wed, Nov 24, 2010 at 5:48 PM, Paul Speed <[email protected]>wrote: > If task "b" needs to run before "a" then "a" needs to depend on "b". > Otherwise, you are hoping that gradle will deduce an implied dependency in > this case... which is maybe a little unfair. > Well I beg to differ since your assumption that a "needs" b is not true as I tried to state in my previous post. b might be only to setup up some context that is "sometimes" needed by a (altering a's behavior) and in other cases not - and I would like to control which context I am working with at that any given time. > > What would happen if task "d" depended on ["a", "b"]? Which should gradle > choose? > Here I would say that explicit dependencies would rank higher than trying to force the order in dependsOn clause. Actually there already seems to be a dependency order enforced from dependsOn (alphabetical), I would argue that this is less elegant way of ordering the tasks than to respect the order from dependsOn. >From the looks of things the behavior I'm after would be the one that you get from running gradle from the command line, passing in two tasks, for example >gradle b a results in b and then a. So to answer your question in other words would be to say: Do it the same way you do it for command line task list. To be fair the scenario might thicken a bit when we get more transitive dependencies into the picture, but I would think in that kind of a scenario you might do some kind of conflict resolution, plus you might argue that it might indicate that the build logic is getting less understandable (unreadable) by humans (-> errors in build logic). Or just ignore the transitive dependency structure the user is trying to set up and do a depth first traversal through the task hierarchy, and let the user work his way through the dependencies to find out why the ordering is not as expected. In my mind it would be easier to find out if the dependsOn order would be respected rather then alphabetical ordering, but that's just me :) > > I think it's probably better to make dependencies explicit. So if "b" must > run before "a" then there is some direct dependency relationship between > them that should be specified. (Though, note that if one depends on the > output of the other that gradle should already figure out the ordering > correctly.) > > I do agree that explicit dependencies are preferable in most cases (not convinced it is the best approach in every scenario - I am a big fan of the answer; It depends) I value being able to do a decorative approach for some tasks and to my defense you might say that the dependency declaration is still in the build file though separated from the tasks in question. Maybe one way to solve this comes to mind, just as I'm writing this (I'm still gonna post this rant :)), might be to try and use <task>.enabled=false. I'll see if I can get that idea to work to the same effect. I might post about it if this pans out. Anyways, thanks for the discussions, still convinced that respecting dependsOn order (if no other order is specified) is a good idea. gretar
