Gradle has no assignments, so how to do it
So if we have a drop db task and a create db task and a server start task and a runqatest task, and we want
- have independent tasks, so I can just call gradle dropdb by itself (or others).
- depend on runqatest from dropdb, createdb, populatedb, startserver
The number 2 obviously needs to be ordered or will break and gradle will not execute in any order like ant. How do you achieve this? (I read a lot about this in this post
http://markmail.org/thread/wn6ifkng6k7os4qn#query:+page:1+mid:hxibzgim5yjdxl7q+state:results
although one user is wrong of not being deterministic when you have 1.e depend on c and d 2.c depend on b a 3.d depend on a, b
since e decides that c will be the first, the assembly will run b, a, c, d, so it is completely deterministic. I agree that parallelizing an assembly is much more difficult if you have ordering, though, as with ant, since you can't just run c and d in parallel is okay (and it's worse than from a user perspective. it doesn't matter the time).
Had they added dependOnOrdered so we can place an order when absolutely necessary.
OR does anyone know how we should do this? The question was filed against gradle in 2009 !!!! I still don't see any documentation in gradle on how to make ordered stuff when needed.
Dean
source to share
Here's one solution:
if (gradle.startParameter.taskNames.contains("qatest") {
qatest.dependsOn startServer
startServer.dependsOn populatedb
populatedb.dependsOn createdb
createdb.dependson dropdb
}
A limitation of this approach is that it only works if it qatest
is part of the original tasks provided on the command line. Sometimes this is good enough and you can add a check so that users don't get it wrong.
If you need this more often, you can add a small helper method to make it easier to declare such a workflow. Something like workflow(qatest, dropdb, createdb, populatedb, startserver)
.
Another approach is to create "clones" of tasks and add task dependencies (only) between clones. Again, you can hide this with a little abstraction. For example, it createWorkflowTask("startServer") { ... }
can create and customize tasks startServer
and startServerWorkflow
.
Thus, Gradle's programmability overcomes the problem that "workflow" is not yet a first-class concept in Gradle.
source to share
Gradle 1.6 added an alternative solution, but it still incubates: mustRunAfter
. See the release notes .
source to share