I know it is possible to extend tasks by inheritance, but that is not what I am after. I am wondering about whether the following is possible
// Let's assume the jar instance of the Jar task for simplicity
jar {
// I want to add a 'abc' method with does some extra stuff during the configuration of the task
abc {
// Do some special stuff in here as part of configuration
}
}
I know it is possible by messing with the metaClass, but I wonder whether there’s a better way.
The idea is that such functionality be added by a plugin.
No, I don’t want to resort to ‘doFirst’ or ‘doLast’. I am interested in seeing whether plugins can add extra methods onto existing tasks, that would be visible during the configuration phase due to closure delegation.
I would think if you want to dynamically add a method to the ‘jar’ task your best option would be using the Groovy metaClass as you’ve said. I’ve used this method for something similar by modifying the ‘DefaultRepositoryHandler’ so as to allow users to do something like:
repositories {
companyNexus()
}
Another thought would be to have your plugin effectively replace the existing ‘jar’ task created by the ‘java’ plugin with your custom task implementation that extends from ‘Jar’.
Tasks are extensible in the same way that Project is. So, you can add extensions (e.g. someTask.extensions.create("foo, FooExtension)) and extra properties (e.g. someTask.myNewMethod = { « method impl })
Was looking at extensions for tasks and got me thinking. What if I wanted to do something with the extension when the @TaskAction annotated method got invoked. Obviously since I don’t one task class inheriting from another I cannot override that method. I could not see any way of hooking into that, so I have to assume that is not possible in 2.0 ??
Thanks Luke. Do you mean that I can write something like this
class mySneakyIntervention implements TaskExecutionListener {
void afterExecute(Task t,TaskState s) {}
void beforeExecute(Task t) {
if (t instanceof FooTask ) {
// Let's make a backup of all the input files
// (Not really sure why you would want to do _that_,
//
but it's an example)
t.project.copy {
from(t.inputfiles.files)
into new File(t.project.buildDir,'backup')
}
}
}
}
and then hook it in, possibly when the plugin gets applied?
project.gradle.addListener( new mySneakyIntervention() )
Also what is the significant differences between ‘TaskExectionListener.beforeExecute’ and a ‘task.doFirst’? Which will be called first?
Another question on task extensions. If I annotate properties in my extension class with ‘@Input’, ‘@InputFiles’ etc., will it be treated the same as if the properties were on the Task itself?
The ‘@Input’ and ‘@InputFiles’ annotations can only be applied to tasks. You could get the behavior you want by using a convention mapping to map your extension properties to your task which would in turn extend ‘ConventionTask’. This is an internal API but this method is used pretty ubiquitously throughout Gradle.
Hey Schalk, as Mark already pointed out, annotations in your extension are not considered. But you could use the Task#getOutputs() and Task#getInputs() to programmatically add inputs/outputs to a given task from your plugin.