On Wed, Sep 12, 2012 at 11:49 AM, Luke Daley <[email protected]>wrote:
> > On 12/09/2012, at 6:33 AM, Hans Dockter wrote: > > > > 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. > > > Maybe an init script coupled with invocation time configurability works > better here. Your init script can apply the build announcements plugin, and > configure it how you want, defaulting to be “disabled”. You could then > selectively “enable” it at invocation time. > Yes. Some form of parameterization in the init script is an alternative. I'm not sure what I like more. 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 > >
