On 18/07/2011, at 3:43 PM, Adam Murdoch wrote: > > 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.
«snip» >> >> 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? We'd need a similar indirection mechanism for every type of class that plugins add where the class object is referenced. But I guess that's only really tasks right now. > 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. Interesting point. In terms of the interface contract it doesn't change the situation all that much though so it's probably not that much of a gain, but it does free up some things I guess. > 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). Are there simple examples of the kind of problems tighter isolation would solve? >> 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. Agreed, but the idea of maybe augmenting the wrapper that you proposed in another thread is probably worth exploring. > I think the way forward is to get rid of the need to use classes statically > in the build script. Right. So in the case where I need to use some kind of POJO (coming from a non plugin jar) as part of my build logic you would just instantiate reflectively? Another thing to consider is that we kind of have a solution already for implicitly extending the build language (kinda) with the buildSrc approach. But, I don't think that helps that much here though where the goal is one line build logic extension as we'd just be moving the code from build.gradle to buildSrc. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
