On 19/08/2012, at 7:42 AM, Adam Murdoch wrote: > > On 17/08/2012, at 8:13 PM, Luke Daley wrote: > >> >> 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. > > I think the benefit is really only in the describing what the project is. > Given a description of a project we can infer a lot of stuff (including what > you can do with it). Describing what you can do with it is often unnecessary, > and often undesired, too.
I should clarify something here: we're talking about automatically applying only those plugins that add behaviour, not plugins that declare something about the project. So, we would not automatically apply: * language plugins: java-base, java, groovy, scala, cpp, cpp-lib, cpp-exe, antlr, javascript. * application plugins: application, war, ear, osgi * publication plugins: maven, signing * code quality plugins. We would automatically apply: * jetty * bootstrap (aka maven2gradle) * idea and eclipse * project-reports * The compare builds plugin * The wrapper plugin -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
