ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Modification of Ant API for AntDSL
Date Sat, 28 Jul 2012 17:35:11 GMT
I think that I would like to change is the following point as documented in the header of the
PropertyHelper class:
"Object value seems valuable as outlined."


Le 28 juil. 2012 à 19:20, Nicolas Lalevée a écrit :

> Le 28 juil. 2012 à 15:54, Stefan Bodewig a écrit :
>> On 2012-07-28, Nicolas Lalevée wrote:
>>> I start to like what I am doing which the AntDSL so I would like to
>>> modify a little bit the Ant API so I can avoid doing so work around.
>> Sorry, I haven't found the time to play with it.
> No worry.
> Though some completely subjective opinion on the "look&feel" of the language will
be appreciated :)
> Anyone ? this is usually a subject for troll :)
>>> In AntDSL, I have introduced an expression language so do some basic
>>> computing: some math, some logical computation and string manipulation
>>> for now. It is intended to replace the property expansion in strings.
>>> Actually, the logical computation is already implemented in Ant: the
>>> Conditions tasks. So I have used them for the if/unless attributes of
>>> the target. I would like to take it back into Ant: [1]. I don't intend
>>> to replace the existing if/unless, just offer new Java API to Target.
>> I think the props Antlib can already do quite a bit of this.
> Actually I work at different level. See below.
>>> I would also like to be able to have expressions in task
>>> attributes. But Ant assumes these are always Strings. As far as I can
>>> tell, there are two places where it is assumed and it would be
>>> changed: RuntimeConfigurable and IntrospectionHelper. I have been able
>>> to work around RuntimeConfigurable and provide my own
>>> implementation. But IntrospectionHelper is final.
>> AFAIR this is not totally true, PropertyHelpers can return Objects and
>> they get picked up in the approriate places.  It is true that
>> PropertyHelpers are the only way to generate non-String values outside
>> of IntrospectionHelper, though.  This is rather limiting.
> I am not sure property helper will do the proper job. I have to admit I don't know them
much, but as far I can tell, they are sort of String parsers. With Antdsl, the parser has
already done the job, I get an instance of the "thing to evaluate", an AntExpression, which
can wrap a Condition for instance.
> So when building an UnknownElement, my project helper cannot call RuntimeConfigurable#setAttribute(String,
String) like ProjectHelper2.ElementHandler.onStartElement() does, I need a RuntimeConfigurable#setAttribute(String,
AntExpression). Thus I would like to introduce a RuntimeConfigurable#setAttribute(String,
> I have also an issue with macros which implement DynamicAttribute. But actually for AntDSL
I think the best would be to reimplement the macros, since I am experimenting getting rid
of the property expansion, and thus probably name them differently, "function" probably.
>>> I have not a patch to suggest, but I think the change would probably
>>> be about introducing an interface Evaluable, change everywhere from
>>> String to Object, and when we try to get the value of the attribute,
>>> if Evaluable call eval(), otherwise call .toString().
>> Do you see any chance to unify this with PropertyHelpers?
>>> The changes I suggest should obviously be backward compatible.
>> Not so obvious to me.  Aren't there any APIs that return String but
>> would return Object with your changes?
> I think that the API are already returning Object, which is cool. But I would need setter
of Object.
> Thank you for your feedback.
> Nicolas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message