On 16/08/2012, at 9:28 PM, Adam Murdoch wrote: > > On 16/08/2012, at 8:39 PM, Luke Daley 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. > > This is much deeper than convenience. This is a change to Gradle's view of > how build logic is structured. What we're doing is separating build logic > into 2 pieces: > > 1. Build logic that describes what the project is, what it represents. > 2. Build logic that provides actions over that project, the things you can do > with it. > > Currently, Gradle expects you to declare both what the project is and the > full set of all things you can do with it. There are a number of problems > with this:
There is also a BENEFIT in that it becomes completely self describing. This shouldn't be discounted. > * Often, there are many things that you can do to a project that can be > inferred from what it is, without needing to declare or configure anything. > For example, any Gradle project can use the wrapper, or any Java project can > be imported into Eclipse. You can't take any project, though you can probably take most. This goes to the point that Steve raised. > * It forces the build author to anticipate every possible use for the project. > > Allowing plugins (i.e. build logic) to be implicitly applied to a project > based on what the project is, gives us a unified, flexible mechanism for > decorating builds to add more "things you can do with it" without changing > the build, or Gradle core. Or without even having a build. This is important > for end users, for tooling, and for us as developers of Gradle. > > What we're doing here is taking the declarative stuff (i.e. here's what this > project is) and cranking it up so you can reuse that information in more > contexts. The only use case I've heard that I find compelling is the IDE use case, and there are caveats there: * We want to push this responsibility to the IDEs themselves * It only works for simple projects -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
