You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Nicolas Lalevée <ni...@hibnet.org> on 2012/07/28 14:39:40 UTC
Modification of Ant API for AntDSL
Hi guys,
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.
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 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.
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().
The changes I suggest should obviously be backward compatible. I also don't think the new API on Target should imply a change in the XML ProjectHelper, an xml syntax of an if condition would probably be ugly.
So is there any comment, objection regarding this API change ?
Nicolas
[1] http://svn.apache.org/repos/asf/ant/sandbox/antdsl/trunk/org.apache.ant.antdsl/src/org/apache/ant/antdsl/Target.java
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Modification of Ant API for AntDSL
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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.
Nicolas
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 :)
>> http://svn.apache.org/viewvc/ant/sandbox/antdsl/trunk/test/build.ant?view=co&revision=1362284&content-type=text%2Fplain&pathrev=1362284
>>
>>>
>>>> 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, Object).
>>
>> 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: dev-unsubscribe@ant.apache.org
>> For additional commands, e-mail: dev-help@ant.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Modification of Ant API for AntDSL
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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 :)
> http://svn.apache.org/viewvc/ant/sandbox/antdsl/trunk/test/build.ant?view=co&revision=1362284&content-type=text%2Fplain&pathrev=1362284
>
>>
>>> 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, Object).
>
> 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: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Modification of Ant API for AntDSL
Posted by Nicolas Lalevée <ni...@hibnet.org>.
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 :)
http://svn.apache.org/viewvc/ant/sandbox/antdsl/trunk/test/build.ant?view=co&revision=1362284&content-type=text%2Fplain&pathrev=1362284
>
>> 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, Object).
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: Modification of Ant API for AntDSL
Posted by Stefan Bodewig <bo...@apache.org>.
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.
> 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.
> 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 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?
> [1] http://svn.apache.org/repos/asf/ant/sandbox/antdsl/trunk/org.apache.ant.antdsl/src/org/apache/ant/antdsl/Target.java
I promise to take a closer look.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org