How can I enforce a chain of task dependency rules (e.g. clean first)?

Old Forum
1

I’d like to create a task with the following sequence of tasks:

clean->update->(compileJava->test)->promote

Each of these is an individual task that may be run without these dependencies. ‘test’ already depends on ‘compileJava’, and ‘promote’ could depend on ‘test’. But how can I set the rest of the path up?

I know the issue of ordered dependencies has been debated before, but I’d like to see what the latest thinking is about how to solve this issue.

Thanks,

Mike

2

The thinking hasn’t changed. Gradle currently doesn’t support this well (see previous debates for approximations), and although it has its uses, it’s needed less often than people think it is. For example, what’s the point of promoting if the code hasn’t been compiled?

3

Let me give a cleaner example. I have a complex, multi-project workspace. I’d like to have two tasks: build and cleanBuild. I want to ensure that clean is executed on every project before any other task.

What is the best way to do this in the current implementation (I’m using 1.0-milestone8a)?

4

Not sure that ‘cleanBuild’ gives much over ‘clean build’, but you could check ‘gradle.startParameter.taskNames’, and if you find ‘cleanBuild’, replace it with ‘clean’ and ‘build’.

5

Peter, I appreciate your responses, but I think we’re still not connecting. I do have cases where “cleanBuild” is preferable to “clean build” (related to CI) and also more complex scenarios.

So, if you started with “cleanBuild” as a requirement, how can it be met?

The argument against implementing this reminds me of the decision for Ant to not include an if clause. I’ve spent many hours coding around that decision. There may have been a good reason for this if we used Ant out of the box exactly the original developers intended. Maven takes this to an extreme where it’s easy to do things as the designers intended, but hard to do anything else. In all other things Gradle is the best of both worlds, implying, but not requiring a conventional approach. I’ve read other posts that have implied that this might prevent Gradle adaptation. A shame, because in all other ways I’ve been able to make the case that I can do anything with Gradle, but unless it’s unusual it’s probably already implemented.

6

So, if you started with “cleanBuild” as a requirement, how can it be met?

I’ve already tried to answer this question (see my previous response).

One of the reasons why Gradle doesn’t offer anything over its task dependency model yet is that it’s still unclear what abstractions to introduce, and how exactly they should work. Such fundamental decisions take time (and the right ideas). All I can say at this point is that I expect Gradle to eventually make advances in this area.

7

Heh, I read your previous answer on my phone and I don’t think the part about the gradle.startParameter.taskNames made it through. That should work.

A question, though: why can’t Gradle provide the same functionality within the scripts as it does in from the command line? That seems like the easy answer. The implementation would take a little bit of thinking, but shouldn’t be difficult.

Thanks for your response.

8

why can’t Gradle provide the same functionality within the scripts as it does in from the command line?

It already does. Setting ‘gradle.startParameter.taskNames’ is exactly that. To achieve your goal, you just need to write a little bit of code that automatically expands task names like ‘cleanBuild’ into lists of task names like ‘clean build’.

Having a way to declare ‘cleanBuild’ as a regular task goes beyond what the command line offers today. Something like this might be supported in the future.