On 11/09/2012, at 6:31 PM, Hans Dockter wrote: > > > On Monday, September 10, 2012, Luke Daley wrote: > I've started trying to write something up for this and have hit some > questions. > > I started thinking about the implications of some kind of mapping between > task names and plugins, which lead to thinking about naming collisions, which > lead to thinking about namespaces. Once you introduce namespaces though, the > characteristics change. > > Yes. > > > I'm pretty sure the initial idea was that `./gradlew idea` would be all you > would need to do auto apply the 'idea' plugin and run the 'idea' task. I'm > now wondering about changing this to be more explicit about applying plugins… > or maybe both. > > Explicitly applying plugins makes somethings simpler. > > 1. We wouldn't need a mapping between tasks and plugins > 2. We wouldn't have to worry about task collisions > 3. It's more discoverable > 4. It's a simpler idea > > To get concrete, let's explore the idea of using `-A«plugin name»` (we might > be able to come up with a better CLI syntax). > > ./gradlew -Aidea idea > > For this case it doesn't offer anything and is less convenient. For > discoverability though, it enables… > > ./gradlew -Aidea tasks > > It also helps disambiguate… > > ./gradlew -Acompare-gradle-upgrade compareBuilds > ./gradlew -Acompare-gradle-migration compareBuilds > > Or potentially for observer like functionality… > > ./gradlew -Aprofile «task» > > > A good example I think is the build-announcement plugin. > > > > There also might be a case where you want a plugin to participate in the > lifecycle… > > ./gradlew -Acobertura build > > (can't think of a great example of this) > > > I don't think any of those are really killer arguments, but I think there's > something there. Plugins don't just add tasks and this would make this > feature more applicable. That said, perhaps it's going to be so common to > want to invoke a task added by the plugin that this is just an inconvenience > and solving a problem (discoverability and name collision) that doesn't > really exist. > > Perhaps this is a separate thing and both would be useful. That is, > inferring plugins to apply based on the requested tasks and the ability to > explicitly apply plugins via the command line. > > For me there is no question that we need to be able to apply plugins from the > command line. I always thought that is the common understanding. Whether we > auto-map tasks to plugins or not is a different question. I like the idea of > auto mapping though.
There is indeed no question about applying plugins from the command line. The question is about whether this is explicit, or implicitly inferred, or both. After writing this I was convinced that there is something that needs to be resolved here, so the current spec is focusses towards exploring this question: https://github.com/gradle/gradle/blob/master/design-docs/invocation-time-plugin-application.md -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
