Re: growl notification plugin

>
>
> 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.