On 16/07/2011, at 1:18 PM, Adam Murdoch 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: 'mytask')
The more I consider this, the more it just feels wrong (by “this” I mean not exposing types from plugins to the build file compile). I can see it being a source of much confusion and annoyance to users. Not having types as first class citizens has an unclean feel to it and seems like a compromise which has the potential to turn people off. I think we need to keep searching for a cleaner solution. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
