« Return to Thread: growl notification plugin

Re: growl notification plugin

by Adam Murdoch-2 :: Rate this Message:

Rene Groeschke wrote:

>
> Am 21.08.2009 um 09:12 schrieb Hans Dockter:
>
>>
>> On Jun 23, 2009, at 9:48 PM, Rene Groeschke wrote:
>>
>>> Hello list,
>>> some weeks ago there was a discussion going on about notification
>>> tasks that make use of twitter, growl, email etc. I've added a
>>> notification plugin to my build, that actually uses Growl for
>>> notifications. I rewrote the notification part in my build logic for
>>> easy reuse. you can reuse it if you want. I've tested it with the
>>> actual gradle trunk.
>>>
>>> I've just created a git repo at github.com. have a deeper look at
>>> http://github.com/breskeby/gradle-notify-plugin/tree/master .
>>>
>>> Actually the growl implementation is hard coded in the notify
>>> plugin. The notify implementation(s) should definitely be more
>>> decoupled. The sources contains some dirty code fragments and
>>> contain no tests yet :-(. I hope to find time to add other
>>> notification implementations soon.
>>>
>>> Comments, suggestions, ideas are appreciated!
>>
>> So far I had unfortunately no time to give this a try. I hope we have
>> a plugin ecosystem infrastructure running within the next two months.
>> This would make it much easier to give new plugins a try and of
>> course to use non-core plugins in general.
>
> I've just updated the code to work with 0.7. BTW. I reorganized my
> github repos and moved this plugin to
>
> http://github.com/breskeby/gradleplugins/tree/master
>
> which is a fork of Gregory Boissinots "gradleplugins" repo.
> Furthermore you can find an ExampleProject in src/samples for easy
> testing. As you can see in the build.gradle of the ExampleProject it
> is actually a lot of overhead to use a thirdparty plugin. I'm really
> looking forward to that plugin ecosystem infrastructure you mentioned.

I count 15 lines of overhead. I think we can make some improvements
right now to simplify this, which don't need any infrastructure, and
which benefit other groups of people who share plugins (eg enterprise
plugins shared by multiple projects).

Let's have a look. The first chunk of overhead declares where to find
the artifacts:

import org.apache.ivy.plugins.resolver.*

buildscript {
repositories {
add(new URLResolver()) {
name = 'breskeby-Repo'

addArtifactPattern('http://breskeby.com/repo/[module](/[branch])/[type]s/[artifact]-[revision](-[classifier])(.[ext])')
}
}
}

A convenience method similar to flatDir() which takes an artifact
pattern would reduce this to:

buildscript {
repositories {
url(name: 'nnn', artifactPattern: 'http://....')
}
}

This also simplifies the build script for those builds which use a
shared repository to share artifacts between builds.

If we had a plugin repository somewhere, we could simplify this a little
more:

buildscript {
repositories {
gradlePlugins()
}
}

And if we made it the default buildscript repository (along with maven
central for the transitive dependencies), then this could disappear
altogether.

The other chunk of overhead declares the plugin to be used:

import com.breskeby.gradle.notification.NotificationPlugin;

usePlugin(com.breskeby.gradle.notification.NotificationPlugin)

buildscript {
...
dependencies {
classpath ":growl-api:0.1"
classpath ':growlPlugin:1.0'
}
}

I assume that 'growl-api' is actually a transitive dependency of
'growlPlugin', and should be moved to it's runtime configuration. We can
also get rid of the import statement, as the fully qualified classname
is passed to the usePlugin() method.

I think we could simplify this by moving the dependency declaration
closer to the usePlugin() statment, which I feel is a better place for
it, so as to keep related things together:

usePlugin(com.breskeby.gradle.notification.NotificationPlugin) {
classpath ':growlPlugin:1.0'
}

If we added some kind of discovery mechanism, this would simplify to

usePlugin('growl-notification') {
classpath ':growlPlugin:1.0'
}

>
> In my opinion it is hard to say if notification should be part of the
> gradle core. I guess the infrastructure for such notification tasks
> (and maybe general implementations like email) should be core, but
> implementations like this macos only growl notification shouldn't.
>

This is a good plan.

Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

« Return to Thread: growl notification plugin