On 16/07/2011, at 7:56 AM, Luke Daley wrote:
> On 16/07/2011, at 7:50 AM, Adam Murdoch <[email protected]> wrote:
>
>> The big downside is that the plugin cannot contribute classes to the build
>> script. But I think it might be a good thing to move away from needing to do
>> this.
>
> How would you manually create a task of a task impl from a plugin?
We'd need to come up with some way to do this. This is the major part of the
'move away from needing to do this'.
One option is to do nothing, so you'd need to use the buildscript { } closure
if you want to use the classes from the plugin in your build script.
Currently, script plugins (ie. scripts applied using apply from: someUrl) also
have the same problem: Task types in the script plugin are not visible to the
applying script. So, it would be nice to have a solution to solve this problem
for both script and binary plugins.
Again, one option is to do nothing, and we just make official the workaround
that people currently use in script plugins:
class MyTaskType extends DefaultTask { ... }
project.MyTaskType = MyTaskType.class
Not wonderful, but not terrible, either. Given this, we could probably add the
new behaviour to apply, and then later provide some better way to share types.
One option would be to do for task types whatever it is we do for plugin types.
Right now, that would mean attaching an id to a task type. Then, you'd do:
task mytask(type: 'mytype') { .... }
There are a bunch of ways we could resolve the type id to an actual
implementation type. It would be nice to keep it consistent with the way we
resolve a plugin id to an implementation type, probably changing how that
currently works to make it easier to attach ids (particularly given it won't
work from a script plugin).
I'd much rather use identifiers than strings to refer to the task/plugin types.
So perhaps we could support something like this:
task mytask(type: types.myTaskType)
Where 'types' is some registry that maps type ids to implementation classes.
Or, with our DSL mapping layer:
task mytask(type: myTaskType)
Alternatively, it might be interesting to move towards the factory method
approach we use throughout the DSL, and allow something like:
mytask = myTaskType { .... }
where myTaskType is a dynamically added factory method that ends up calling
project.task(type: types['myTaskType'], name: 'mytask')
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
