Re: growl notification plugin

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