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:20:40 GMT

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.


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

View raw message