Deriving from another Task class (not DefaultTask) when creating a new Task class

Old Forum
1

I suspect this is a pretty noob question, howver I just cannot get my head around this one.

I am trying to create some wrappers around legacy build tools such as GNU Make & SCons as part of a migration. The idea is to create some Task classes to do this, but since these would really just be calling out to executables I thought it would be great if I could just re-use most of what already happens with the Exec task.

An example of this code is on Gist: https://gist.github.com/ysb33r/5554324

I would like to have some additional properties such as targets. i.e should the target be ‘install’, the task would end-up calling ‘make install’. It would achieve this by setting executable and args properties. As per the code snippet in the link, I would like to this to happen transparently to the caller. The latter should only need to set the targets property in the closure as which is the convention for tasks. When the tasks is executed it should automatically populate ‘args’ in the parent ‘Exec’ task.

For custom tasks one would just use doFirst to achieve this, but how to achieve this inside a task class?

2

It’s probably better to design a task type from scratch (based on ‘DefaultTask’) and use ‘project.exec’ internally (composition over inheritance).

3

Thanks Peter, I was thinking someone was going to suggest using composition. Anyways, it was the project.exec that did the trick. I have updated the Gist with a new version.

4

Peter, can you clarify why (conceptually) this is better? I’ve been struggling with this myself and keep running into issues with decorators. Based on your answer I think I’ll rewrite them as you suggest, but I’m curious about the design guidelines. Is it ever OK to derive from a task implementation? Or should we always extend DefaultTask and delegate?

5

Thanks to this, I have managed to create a GNU Make Task Class, which is available on GitHub (https://github.com/ysb33r/Gradle) and the binary is on Bintray.

It won’t be of use to many people here I guess, but it definitely helps those of us involved in migrating legacy build systems.

6

Nice work!

We’ll give it some press.