On Tue, Sep 11, 2012 at 7:31 PM, Hans Dockter <[email protected]>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. > I have thought about this a little bit more. A main use case for me is to have some aliases where I can run Gradle with build-announcement, other reporting/debug/profile plugins or not. I can achieve this also by using different init scripts. It is less convenient though. On the other hand plugins need to be applied differently (e.g. some only to the root project like build-announcement) so the init.gradle gives me full control here. Hans
