On 16/07/2011, at 1:18 PM, Adam Murdoch <[email protected]> wrote:
> > 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: Seems like we'd have to do some kind of indirection this for any kind of type the user wants to use directly, which doesn't seem all that scalable. Have you considered another kind of file that sets up the dependencies of the build language instead of doing it in build.gradle. I haven't really thought that through. Regardless though, I think some of the suggestions above make sense for tasks anyway for convenience.
