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/

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

    http://xircles.codehaus.org/manage_email