CODEWITHSUNDEEP
gradle
Dean Hiller
Dean Hiller

Reputation: 20182

gradle has no task ordering so how to achieve this

So if we have a drop db task and a create db task and a start server task and a runqatest task and we want to

  1. have independent tasks so I can just call gradle dropdb by itself(or the others as well)
  2. have the runqatest depend on dropdb, createdb, populatedb, startserver

Number 2 above obviously needs to be ordered or will break and gradle does not abide by any order like ant does. How to achieve this? (I have read plenty about this on this post

http://markmail.org/thread/wn6ifkng6k7os4qn#query:+page:1+mid:hxibzgim5yjdxl7q+state:results

though the one user is wrong on it 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 c will be first, the build would run b,a,c,d so it is completely deterministic. I do agree that parallelizing a build is much harder if you have order though like ant does as you can't just run c and d in parallel as order matters(and it's worse as from a user perspective, it does not matter most of the time).

If only they would add a dependsOnOrdered so we can do order when absolutely necessary.

OR does anyone know what is the way we are supposed to do this? The issue was filed against gradle in 2009!!!! I still see no documentation in gradle on how to do ordered stuff when needed.

Dean

Upvotes: 3

Views: 1459

Answers (2)

Daniel Beck
Daniel Beck

Reputation: 6513

Gradle 1.6 added an alternative solution, but it's still incubating: mustRunAfter. See the release notes.

Upvotes: 3

Peter Niederwieser
Peter Niederwieser

Reputation: 123890

Here is one solution:

if (gradle.startParameter.taskNames.contains("qatest") {
    qatest.dependsOn startServer
    startServer.dependsOn populatedb
    populatedb.dependsOn createdb
    createdb.dependson dropdb 
}

The limitation of this approach is that it only works if qatest is part of the initial tasks provided on the command line. Sometimes this is good enough, and you can add a check to make sure that users don't go wrong.

If you need this more often, you can add a little helper method that makes it easier to declare such a workflow. Something like workflow(qatest, dropdb, createdb, populatedb, startserver).

Another approach is to create "clones" of the tasks, and add task dependencies (only) between the clones. Again, you could hide this behind a little abstraction. For example, createWorkflowTask("startServer") { ... } could create and configure both a startServer and a startServerWorkflow task.

In summary, the programmability of Gradle makes it possible to overcome the problem that "workflow" isn't yet a first-class concept in Gradle.

Upvotes: 5

Related Questions