On 16/11/2011, at 3:09 AM, Adam Murdoch wrote:
> With the build-announcements plugin, we have a plugin that:
> * should only be applied once per build.
> * needs to be usable from an init script
> * needs to be usable early in the build, before we've loaded any projects.
We shouldn't use the term “global” plugin for this. To me, that term conveys
that it's going to be in every Gradle build I touch. There may be a case for
this type of plugin one day. I think what we have with the announce plugin is a
“build” plugin, or “build-wide” plugin (opposed to a “project” plugin).
> Which suggests that it should be applied to the Gradle instance, rather than
> a particular project. That is, in an init script you'd do this:
>
> apply plugin: 'build-annoucements'
>
> And in a build script:
>
> gradle.apply plugin: 'build-announcements'
>
> or perhaps just:
>
> apply plugin: 'build-announcements'
>
> knows that this plugin's target is a Gradle instance and applies it to the
> Gradle instance instead of the Project instance.
>
> Not sure what to do about configuration for this kind of plugin. If we
> followed our current pattern, we'd use an extension on the 'gradle' object:
>
> // init.gradle
> apply plugin: 'build-announcements'
>
> announcements {
> sendTo growl
> sendTo email { .... }
> }
>
> // build.gradle
> gradle.apply plugin: 'build-announcements'
>
> gradle.announcements {
> ....
> }
>
> It's a bit awkward having to use a different namespace in different scripts.
I'm not sure the namespacing is a problem. To me it makes sense and reflects
the API of each point.
For this particular plugin, why can't it be a “project” plugin? Are we sure
that all subprojects in a large project will want the same announcement
configuration?
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
