Granularity of tasks


(William Zeitler) #1

I’m an old hand c++/nmake guy, newbie to gradle. I’m working on implementing my current java project. This project requires me to generate java source files, a task requiring copying files to a temp folder, massaging them, etc.

I’m wondering about ‘best practices’ pros/cons of breaking each ‘sub-task’ down into a separate task:

task subTask1 {
    copy some files
}
task subTask2 {
    dependsOn subTask1
    run a build tool 
}
task subTask3 {
    dependsOn subTask2
    copy some more files
}

(inputs & outputs statements omitted for simplicity/clarity)

Versus combining tasks that in practice make no sense to run incrementally – if there is any change in the source, ALL must be run:

task myTask {
    copy {
        copy some files
    }
    javaexec {
        run a build tool
    }
   copy {
        copy some more files
    }
}

THANX!


(Stefan Oehme) #2

I’d generally lean towards fine-grained tasks.

Fine-grained tasks mean that you do less unnecessary work. For instance, if the javaExec step failed because of a wrong configuration, then you don’t need to re-run the first copy. If you combine them into one task, then you’d be doing some unnecessary work.

Also, if the output of the copy task is the same, then the javaExec task doesn’t even need to run. This could be a big deal, depending on how big the input of the copy is compared to its output.

On the other hand, if all of the steps work on pretty much the same inputs and maybe even massage stuff in the same output dir, then it doesn’t make sense to split them.