On 16/07/2011, at 4:31 PM, Luke Daley wrote: > 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.
Not scalable in what sense? There are some benefits to having the indirection. One important one is that the implementation class is no longer exposed to the user. Right now, the task implementation class is used as the identifier for the task type. This means everything statically reachable from the implementation class leaks onto the public API of the plugin. The other main advantage is that it solves a problem we've been trying to crack for quite a while. Exposing just enough of the plugin/script classes in just the right places is something we don't have a good solution for yet. So, the indirection approach is a pragmatic solution, rather than an ideal solution. It is a pretty simple solution and easy to implement, and lets us move forward on usability for build script authors, though plugin authors might take a small hit (but we can probably automate that). > > 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. You used to specify build script dependencies in settings.gradle, back in the day. I don't really want to go back there. I think the way forward is to get rid of the need to use classes statically in the build script. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
