On Aug 16, 2012, at 9:08 AM, Hans Dockter wrote:
>
>
> 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.
+1
>
> 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.
+1
>
> 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
>
>
