« Return to Thread: a standard way to enhance the GDK using Java code using META-INF/services/groovy/groovyMethods files...
Re: a standard way to enhance the GDK using Java code using META-INF/services/groovy/groov
by Tom Nichols
::
Rate this Message:
Actually I like this idea. How about...
Look at _everything_ under that folder on the classpath, and parse all
of them for extensions. That way, library x can contain extension
methods for classes A and B, and library y can contain extensions for
C. Since they are all parsed at once, it would be a "fail fast" if a
second library contained conflicting extension methods. Or you could
just say classpath order determines preference.
I found a way to hard-bake categories into the metaclass:
class XPathCategory {
static getNode( node, expression ) {
...
}
//other methods
static apply() {
addMethod( XPathCategory.&getNode )
//add other methods...
}
private static addMethod( newMethod ) {
Node.metaClass."$newMethod.method" << { exp -> newMethod( delegate, exp ) }
NodeList.metaClass."$newMethod.method" << { exp -> newMethod(
delegate, exp ) }
}
}
Attached is the full example for XPath methods on an org.w3c.dom.Node
and NodeList. (Don't concentrate too much on the usefulness of this
specific application.) If that XPathCategory class was put into a
certain classpath location and automatically parsed at startup and
apply() called, that would be super-awesome :-)
-Tom
On 9/12/07, James Strachan <james.strachan@...> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
Look at _everything_ under that folder on the classpath, and parse all
of them for extensions. That way, library x can contain extension
methods for classes A and B, and library y can contain extensions for
C. Since they are all parsed at once, it would be a "fail fast" if a
second library contained conflicting extension methods. Or you could
just say classpath order determines preference.
I found a way to hard-bake categories into the metaclass:
class XPathCategory {
static getNode( node, expression ) {
...
}
//other methods
static apply() {
addMethod( XPathCategory.&getNode )
//add other methods...
}
private static addMethod( newMethod ) {
Node.metaClass."$newMethod.method" << { exp -> newMethod( delegate, exp ) }
NodeList.metaClass."$newMethod.method" << { exp -> newMethod(
delegate, exp ) }
}
}
Attached is the full example for XPath methods on an org.w3c.dom.Node
and NodeList. (Don't concentrate too much on the usefulness of this
specific application.) If that XPathCategory class was put into a
certain classpath location and automatically parsed at startup and
apply() called, that would be super-awesome :-)
-Tom
On 9/12/07, James Strachan <james.strachan@...> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
XPathCategory.groovy (2K) « Return to Thread: a standard way to enhance the GDK using Java code using META-INF/services/groovy/groovyMethods files...
| Free embeddable forum powered by Nabble | Forum Help |
