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.
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»
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.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
