Does 1.6 version really fixed isse [GRADLE-427] dependsOn doesn't respect dependency order


(Mayura Viraj) #1

Hi

I’m using gradle 1.6 and , in my build dependsOn does not give the order i specified,

Ex:

task a << {
    println "a"
}
  task b << {
    println "b"
}
  task c (dependsOn: ["b","a"]) << {
    println "c"
}

When i execute gradle c , i got following result

:a
a
:b
b
:c
c

I was expecting to see following:

b
a
c

If dependsOn pick tasks in alphabetical order what’s point of having dependsOn. I mean i’m giving a order in dependsOn because i want to exactly follow that order.


(Corneil du Plessis) #2

Imagine the dependencies list as a set instead of an array or ordered list. You should add dependency on ‘b’ to ‘a’ if you need ‘b’ to execute before ‘a’


(spencer_allain) #3

Gradle 1.6 did not change the behavior of dependsOn(), as that is always intended to simply define a dependency, not any relationship of ordering between any dependent tasks. Running alphabetically is the current implementation behavior, but not to be relied on.

What Gradle 1.6 did add was a mustRunAfter() concept applied to tasks that specifies an ordering between tasks to run, but does not impose a dependency that the referenced tasks must always run, only that the order that they would run in is in effect if they are all in the task graph due to actual dependencies or requested at build time.

task a << {
    println "a"
}
task b << {
    println "b"
}
task c (dependsOn: ["b","a"]) << {
    println "c"
}
a.mustRunAfter(b)
  task d {
  dependsOn b
  doLast { println "d" }
}

Consider the above build.gradle file and invoking the following tasks from the command line: gradle -q c

b
a
c

gradle -q d

b
d

gradle -q d a

b
d
a

gradle -q a d

b
a
d

gradle -q b

b

gradle -q a b

b
a

dependsOn() imposes a shall-always-run relationship (hard dependency) mustRunAfter() imposes an ordering relationship but not a shall-always-run relationship (soft dependency)

-Spencer


#4

I think Adam describes the reasoning behing closing this issue pretty well in his comment on GRADLE-427.