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 Mon, 30 Jul 2012 21:16:39 GMT
I have looked into the actual implementation details, actually I don't need much. So little
that I have committed them, it will be easier to review, easier than writing about it in an
email. If I can do this with a PropertyHelper, I'll revert and use the non intrusive way.


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

> 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."
> Nicolas
> 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:

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

View raw message