growl notification plugin

[RenŽé Gröschke]

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!

regards,
René


-----------------------------------
René Gröschke
rene@...
http://www.breskeby.com





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

    http://xircles.codehaus.org/manage_email

[hdockter]

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 think notification functionality is something truly general. So such  
a plugin might end up in the core at one point.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[RenŽé Gröschke]

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.

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.

regards,
René

ps.: no berlin.jar this year :-(


-----------------------------------
René Gröschke
rene@...
http://www.breskeby.com





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

    http://xircles.codehaus.org/manage_email

[hdockter]

On Aug 24, 2009, at 11:38 PM, 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.
>
> 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.

I agree.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

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

[RenŽé Gröschke]

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
rene@...
http://www.breskeby.com





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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Rene Groeschke wrote:

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

It needs to end up in a dependency descriptor published alongside the
plugin. At this stage, that could be an ivy.xml or a maven pom, as you
choose. If you add growl-api to the runtime configuration of the
plugin's build.gradle, then Gradle should take care of generating the
descriptor and publishing it.


Adam


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

    http://xircles.codehaus.org/manage_email