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
