ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: Extending Ant [was RE: Comparing files in subdirectories]
Date Wed, 30 Oct 2002 19:04:11 GMT
Erik Hatcher wrote:

> Costin Manolache wrote:
>>>For example, a property representing a file could be used in a situation
>>>where only the basename is wanted: ${}
>> I think we mean the same thing -  my 'test case' uses
>> jxpath and velocity to navigate object hierarchies, so if 'file' is
>> a reference or some object you could navigate through its properties
>> ( and probably methods ) without problems.
>> It should be also trivial to plug in any other form of property
>> evaluator - including one that is specific to file. Something like
>>   ${file:baseneme:myProperty}
>> The property interceptor can 'resolve' any expression - so I guess your
>> format can also be supported ( as long as you plug a hook impl. that
>> detects and resolves it - but I don't particulary like the syntax you
>> sugest ).
> The syntax, of course, is up for discussion and as your design allows,
> pluggable!  :)

My general thinking is that everything that depends on personal taste
( or needs ) should be more or less pluggable :-)

Besides taste, easier integration with existing patterns ( beans, 
jxpath/velocity/jelly navigation and syntax, etc ) is an important issue.

> I was following MessageFormat syntax, which seems like a reasonable
> scheme to emulate.  What I meant by "" was something set
> this way:
> <property name="" location="someFile.txt"/>

I think having a scheme to avoid backward compat problems is important.
My current proposed solution has 2 elements: the property interceptor 
requires to be explicitely enabled ( by using a task that plugs in the 
mechanism - explicitely, so older files will keep working ).
And I use "prefix:expression" scheme to avoid some conflicts and to 
enable easy parsing ( if multiple mechanisms are supposed ).

>> The end result would be that the property and reference storage and
>> evaluation will be decoupled from ant core and delegated to user-space
>> tasks.
> Interesting.  Definitely food for thought.  I'm not convinced that the
> storage should be decoupled from the core, but perhaps more discussion
> could convince me.

I'm not convinced either :-)

But I see value from an integration ( embeding :-) perspective. Something
like netbeans/eclipse/idea ( or tomcat ) could benefit from.

> By the way, I attended a JMX presentation this past weekend and have
> been mulling over how MBeans could be used as well :)

I'm _very_ glad to hear that !! I really hope this discussion will start

I have one piece of experimental code that turns each ant task into
an MBean automatically and without any change in the task itself ( it's 
using tomcat DynamicMBean, which can turn any java bean into an mbean using 
introspection ). It is  also quite easy to provide MBean interfaces to 
Project and Target. So the entire ant can be used as a collection 
of mebeans and manipulated using jmx.

The other side is having ant tasks to control/load/manipulate MBeans.
I want to finish this before tomcat5.0 ( and use this as a way to
start/configure tomcat inside ant ). 

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

View raw message