On Thu, Aug 16, 2012 at 4:08 PM, Hans Dockter <[email protected]>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. > > 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. > There is even more to it. There is obviously need for what we now model as our internal tasks. You don't want to ask people to add the dependencies report plugin because most of the time they don't want anything special (possibly similar to the ide use case). Or take the projects task. I think there is no argument that there is an important use case behind the internal tasks. But the internal tasks are not a nice solution for this. I think it is an unnecessary additional concept which is not extendible, that solves this problem for the most obvious scenarios in an ad hoc way. With auto applying plugins we can get completely rid of it and any task can now be used this way. When we added internal tasks we always considered it an ad hoc solution and knew that they will be replaced by auto applying plugins some day. Another good use case is the build-announcement plugin. I can of course apply it in the init.gradle in user.home for all builds. But I might want to use is only for some projects, I might want to use an alias that runs gradle with the build-announcement plugin, etc... Which leaves me with one question. How would we auto-apply a plugin that has no tasks? I'm sure there will be a significant set of more very interesting use cases. It is another important piece of the toolkit story where we can embrace the unanticipated and make custom requirements extremely convenient to deal with. Hans
