ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: Extending Ant [was RE: Comparing files in subdirectories]
Date Tue, 29 Oct 2002 23:51:59 GMT
Erik Hatcher wrote:

> Costin Manolache wrote:
>> Another hook I'm lobying for deals with replacement of ${properties}.
>> I'm experimenting with a more advanced one that would allow
>> "${ref:reference}" to actually call a setter using the real
>> reference type ( foo="${ref:a} -> setFoo( Bar param ), where 'a'
>> is a reference to a Bar type ). That would require hooking into
>> IntrospectionHelper - and I can tell you it's not very hard.
> 
> Yes, that is a cool feature.  I brought up something perhaps related
> once upon a time when the <basename>/<dirname> tasks were being put in
> such that you could have MessageFormat-like replacements (see how a {0}
> being fed with a Date can be flexibly formatted).
> 
> For example, a property representing a file could be used in a situation
> where only the basename is wanted: ${file.property:basename}

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 ). 

> That syntax might not be quite the end implementation, but something
> along those lines so we don't need to keep adding property morphing
> tasks, we can simply have the underlying data structure have getters or
> something like that to return pieces.  So dirname, toUpper, toLower, O/S
> conversions and the like could all fit into that realm.

All that's not only easy to do, but can be done as user-space tasks - 
so it doesn't have to be supported in ant core.

And it also works for ant1.5 :-)

> This would mean that, perhaps, properties aren't simply strings but
> represent a richer Object instead.  <tstamp> for example could create
> the properties as real Date objects and rather than formatting them
> itself the formatting could be done at the time of its use.
> 
> These ideas might be tangential to where you were going with this,
> Costin, but I figured while it was on my mind :)

I think I'm going in a similar direction - all this can be easily 
implemented using PropertyInterceptor hook.

There is only one open issue I want to find an answer to before
making a proposal for the main branch - and that's what happens
with setting.

It would be easy to also intercept property setting ( <property .. >)
and eventually to extend this to reference setting and getting - so 
different plugins can be notified about both events.
With a 'special' Hashtable we can provide full backward compat.

The question is if it is a good idea and if it should be done in the
same chain with the property getter.

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. 

Right now I'm leaning to a small-steps aproach, but I would like 
to know if this would work and how.

Costin



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message