On 16/11/2011, at 8:46 PM, Luke Daley wrote:
>
> 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).
'build plugin' is good.
>
>
>> 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?
I think there're 2 reasons:
* These are build-wide announcements: build successful, build failed, task
failed (for use with --continue), probably tests failed at some point. It
doesn't make sense for each project to generate these events.
* These event can be fired before any project comes into existence (eg a broken
init/settings script, a test failure in buildSrc, a broken dependency in a
buildscript { } section, etc).
That's not to say a project build script won't configure this plugin, to
add/change/remove an announcement destination.
Let's see what use cases come up from people using this.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
