ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: [RT] [myrmidon] Property evaluation
Date Mon, 22 Apr 2002 15:39:52 GMT
Isn't JNDI the natural fit for this kind of looking up stuff inside other
stuff? XPath is great for accessing XML stuff inside XML, but JNDI is real
powerful on the Java side. In Peter's example, mds is wrapped in a context,
and itemX are leafs of that context, but could be sub-contexts too if they
had "children" of their own.

Now that I know JNDI, I see tons of APIs that do similar stuff in lots of
code (including the JDK) that could be replaced by one and only one API,
JNDI. I'm curious how very experienced Java developers like you guys feel
about that, and why JNDI doesn't come up immediately to you in a situation
like this?

I'd appreciate your insights. Thanks, --DD

-----Original Message-----
From: Adam Murdoch [] 
Sent: Sunday, April 21, 2002 2:53 AM
To: Ant Developers List
Subject: Re: [RT] [myrmidon] Property evaluation

On Sun, 21 Apr 2002 14:13, Peter Donald wrote:

> We could create our own expression language or clone it from an existing
> project (maybe velocity). However I believe there is an XPath library at
> Apache that is meant to be damn fine (Jaxen in commons IIRC) that we could
> use (Not sure I personally haven't looked at it but it is meant to be all
> good).

This would be quite cool.  Personally, I'd prefer an 
objects-with-properties-and-methods model like velocity, to a 
tree-of-nodes-with-a-value model like xpath.  Mainly 'cause it maps to java 
more naturally (and, well, the property values are java objects, after all),

and extends more cleanly.

But, it doesn't really matter, I suppose, since it's so easy to swap
resolvers now.  We can have a whole bunch of expression languages.  And once

we get services happening at task scope, you could use a different
language for each task (don't reckon that would make it into the elements of

ant style, though :)


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message