On Thu, Aug 16, 2012 at 12:39 PM, Luke Daley <[email protected]>wrote:
> > On 16/08/2012, at 1:30 AM, Adam Murdoch wrote: > > Hi, > > Something we've wanted to do for a long time is have some way to > automatically apply a plugin when you run Gradle from the command-line > and/or IDE. There are a number of nice usages for this: > > * Running 'gradle idea' automatically applies the idea plugin and runs the > 'idea' task. This is useful, for example, when working with an open source > project whose developers don't use IDEA. Same for the eclipse plugin. > > * Running 'gradle wrapper' automatically applies the wrapper plugin and > runs the 'wrapper' task, which sets up the wrapper to point at the current > version (the wrapper plugin doesn't exist yet). Or running 'gradle > wrapperLatestRelease' automatically applies the wrapper plugin and runs the > 'wrapperLatestRelease' task, which sets up the wrapper to point at whatever > the version at http://services.gradle.org/versions/current happens to be. > This is useful for managing which version your build needs, without needing > to have these tasks defined in your build. > > * For the new bootstrap and upgrade/migration plugins, you'd be able to > run 'gradle bootstrap' or 'gradle checkUpgrade' or whatever, without having > these defined in your build. In particular, it would mean you could go to a > directory containing a Maven build and no Gradle stuff, run 'gradle > bootstrap' and you've got an initial Gradle build. > > * It would allow us to move some stuff out of core and into plugins. For > example, the daemon management command-line options like --stop could > instead be a task in a plugin. And this would give as a good place to add > more daemon stuff (e.g. query the daemon status). Or the help tasks and > reporting tasks could live in a plugin. Or the profiler could live in a > plugin, which would allow us to offer more report formats and so on. > > > Off topic: Why is this option “--stop”? What is it stopping exactly? The > world? > > The basic idea is that when an unrecognised task name is specified for a > build, Gradle will look for a plugin that provides that task, and apply the > plugin. Initially, we're only interested in providing this for built-in > plugins, but definitely want to extend this to custom plugins at some point. > > > I'm not convinced about the auto apply of plugins. I can see the > convenience of it, I'm just not sure it's worth the cost. However, if it > facilitates moving more “core” functionality into plugins then that's > enough for me… though there might be other ways to do this. > There is also the templating/archetype use case. As you pointed out, modularization is very important in this context. I think also that it is extremely uncool that you have to modify the build script of a project where you are not a committer to let it generate metadata for let's say idea. I think there is a convenience we can provide with that which is pretty important in a variety of scenarios. Additionally it is also something people would expect, specially when coming from Maven. Hans > > For me, this is also pretty far down the list of priorities. I'd be more > impressed with good tools for verifying Gradle upgrades than the fact that > I can do it with adding anything to my buildscript. > > There are a few basic approaches to how a plugin declares which tasks it > provides: > > 1. We maintain a hardcoded list in core. > 2. We add a resource that we can find using ClassLoader.getResources(), > called, say META-INF/gradle-plugins/meta-info.properties. > 3. We add something to the existing > META-INF/gradle-plugins/${plugin}.properties. > 4. We add some annotations to the plugin implementation. > > Options 1 and 2 are easy to implement. Options 3 and 4 require us to scan > the classpath and cache the result. But, we need to do this kind of thing > anyway (invalidate task outputs on implementation change, plugin-provided > services, declarative extensions and the like). > > Options 2, 3 and 4 mean auto-apply would be available for custom plugins, > provided you're using a custom distribution or an init script. > > Option 4 means we can include this information in the DSL reference. > > We might combine options, so that you use annotations in your source and > at build time we generate an easy-to-find resource. > > Implementation-wise, there are a bunch of issues to sort out: > > * How does a user discover the full set of tasks that are available? > Include them in the output of 'gradle tasks'? A new report? The DSL guide? > All of the above? Something else? > > > There has to be a way for a user sitting in front of a build to determine > *all* of the things they can do with it. I don't like the idea of magic > tasks that there is no way I can know exist at all. > > * What do we need to expose through the tooling API? > > * How do we deal with plugins that should be applied once per build > (wrapper, bootstrap, profile, etc) vs those that need to be applied to all > projects (idea, eclipse, etc)? > > * How will this interact with camel case matching? Do we consider first > the set of declared tasks, and then second the set of implicit tasks, or do > we consider them all in one set? > > * How will this work for build types? (and, what is a build type? :) > > * How do we make this work for custom plugins? > > This last question is interesting. We might use the plugin portal here, to > serve up meta-data about plugins. We'd hit some web service, give it > (gradle version, task name) and get back a list of candidates. The result > would be cached, of course, and we're respect the --offline flag. Doesn't > help with custom plugins for the enterprise, of course. > > > I'll think some more on it, but I'm not big on this idea. As I said, I'm > just not sure the convenience is worth the cost. > > > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > >
