On Mon, Sep 21, 2009 at 5:30 PM, Adam Murdoch <[email protected]> wrote:
<snip> > I wonder this too. I'm leaning towards the above. > > I suspect that source sets won't be the only domain objects that we will > want to extend at runtime using plugins, whether that's directly via > usePlugin() or indirectly with some kind of type or role property). I can > imagine builds, repository containers, configurations, dependencies, and > maybe even tasks should be extensible in this way. > > The question is, do we apply plugins to projects only, and have some other > type-specific mechanism for other types, or do we generalise the plugin > concept to allow pretty much any type to be extended via usePlugin(). In > other words, what's so special about projects that they are the only > extensible things that are extended using usePlugin()? > > Another option is to rename usePlugin() to something that fits a bit more > generally. > Well, projects are special because they are the "main" concept of Gradle. However, I agree that other things might want to be extensible. I think useExtension() would be a better name than usePlugin() even if projects were the only extensible thing, but especially if they are not. If one thinks about it, a plugin right now is just a collection of extensions to things such as tasks, rules, and conventions. By breaking up a plugin into finer grained extensions you might enable better reuse of functionality, but I'm not sure. Right now, many of the things that plugins extend all build upon one another, so it might not be so easy to break apart... -- John Murph Automated Logic Research Team
