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.

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
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

Reply via email to