Hi Luke, On Tue, Sep 11, 2012 at 7:40 PM, Luke Daley <[email protected]>wrote:
> > 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. > I mean there is the use case for explicitly applying a plugin. > > 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 > You are absolutely right. I forgot to mention in my other email that this was a very good write up of different use cases. If my answer came across as that the solution to this problem is obvious I didn't mean that. We need to explore. I just wanted to say that we have to be able to explicitly apply a plugin as some plugins, mostly because some plugins are not task driven. I also think that auto mapping tasks to plugins can provide a great user experience for a lot of common activities. Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleware CEO, Gradleware - Gradle Training, Support, Consulting http://www.gradleware.com > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > >
