Plugins: Complex Custom task type or dependency chain?

[mpern (Markus Perndorfer)]

My question is similar to the one asked here:

Complex task or dependency chain?

I’m curious about what is the more “gradle” way to implement a complex task, as multiple small tasks that depend on each other, or as a single task doing a lot of work. This stems primarily from the fact that it’s often easier to configure individual tasks, but it’s harder to get an overview, and in my particular case, the tasks aren’t that meaningful on their own. Example pseudo code: task modifyZip << { exec { delete old files } ant.unzip { the files } exec { operate on extracted files } …

The difference is:

I’m trying to write a Gradle plugin (in Java) and one of the tasks it should provide requires multiple processing steps (build, generate some custom folder structure in a temp folder, copy and generate files, zip everything together and a few other things).

Should I hide this complexity in a huge custom task class (and possible re-implement a lot of stuff) or preconfigure smaller tasks + dependencies to leverage task types gradle provides out-of-the-box?

What’s the more “gradle” solution for plugins?

[bmuschko (Benjamin Muschko)]

I’d create one task for each step and chain them together with task dependencies. The benefit is that is easier to use core task types and you know exactly what failed if something fails.

[st_oehme (Stefan Oehme)]

Also you get finer grained caching and up to date checking that way. If step one produces the same output, then step 2 and 3 will be up to date. If everything is in one big step, it’ll all rerun.