Hello,
first of all thanks to have a look at the code and for your suggestions.
Am 26.08.2009 um 01:21 schrieb Adam Murdoch:
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.
You're right, in this case 'growl-api' is a transitive dependency
needed at runtime. but I have a question to that: Where should the
runtime configuration (including the dependency to ':growl-api:0.1')
for a plugin be defined, respectively stored?
regards,
René
-----------------------------------
René Gröschke
[email protected]
http://www.breskeby.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
