Re: a standard way to enhance the GDK using Java code using META-INF/services/groovy/groovyMethods files...

> I've just got an excuse to play with Groovy again after a rather long
> quiet time; I'm busy hacking a little Groovy DSL for Apache Camel...
> http://activemq.apache.org/camel/
> (I can imagine the logo already BTW; a camel with shades and flared
> disco trousers... ;-)
>
> Firstly - great work everyone! Groovy's really come on in leaps and
> bounds since I last used it. Also the IDEA plugin is amazing! (I found
> I had to use the latest EAP; I struggled with 7.0 M2 to no avail).
>
> So I found the easiest way to implement my little DSL was to add some
> extra groovy methods to various types. (These methods needed to be
> added to some base classes too, so the GDK type additions being a
> really nice way to solve this issue).
>
> I know I can do this with categories; but I really wanted to hard-bake
> in these extra methods with the actual library so its not really
> possible to not have these methods around. i.e. I'd like
> camel-groovy.jar being on the classpath to auto-register some groovy
> methods for working with Camel in a groovy way.
>
> I took a quick peek at the grails stuff for adding extensions and
> didn't quite grok it but it looked like it was doing clever stuff
> doing pattern matching and whatnot - I guess for the find by methods
> for ORM etc. The methods I need to add are pretty simple and need to
> be typed (need multiple methods with same name but different
> parameters). I wondered what the current approach was in Groovy?
>
> I kinda liked the idea of a way to expose new groovy methods in other
> libraries that just kinda gets wired up by default if the library is
> on the classpath; particular for library developers to be able to ship
> a separate groovy jar with their library for folks wishing to work
> with groovy and their library.
>
> I couldn't see any other option (forgive me if I missed something) so
> took a little stab at a simple implementation. Namely, if a file
> called
>
>   META-INF/services/groovy/groovyMethods
>
> is found on the classpath then its parsed (lines starting with #
> ignored) then any non-whitespace lines are tokenized on ",", removing
> all whitespace and then assumed to be a Class which defines instance
> groovy methods. Then for static methods we look for...
>
>   META-INF/services/groovy/groovyStaticMethods
>
> So in Camel's case, we write a file called
> META-INF/services/groovy/groovyMethods that contains
> "org.apache.camel.groovy.CamelGroovyMethods" and then hey presto;
> anyone with the camel-groovy jar on their classpath gets nice DSL
> magic.
>
>
> Its a pretty trivial patch - and is really easy to back-out if there's
> a better way of doing this. I don't seem to have commit karma any
> more, so I've raised a JIRA and attached the patch for review...
> http://jira.codehaus.org/browse/GROOVY-2116
>
> I'm sure there's another way tinkering with the
> MetaClassRegister/MetaClass stuff; I just liked this simple approach
> as its nice and simple & hard to break & is barely any code etc.
>
> Thoughts?
> --
> James
> -------
> http://macstrac.blogspot.com/
>