ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Ant2 and properties
Date Mon, 04 Dec 2000 14:08:44 GMT
At 12:30  5/12/00 +1100, Conor MacNeill wrote:
>> Okay - I was thinking that something like this would be
>> useful to unify all
>> the different data-types.
>> <property name="foo">
>>   <mydata-type attr="1">
>>   ...blah...
>>   </mydata-type>
>> </property>
>I certainly support unifying properties and the other datatypes. I had
>originally just seen this as making property a string datatype, using
>the same namespace and passing to subprojects, etc. What you are
>suggesting above is a little different. With the above we would probably
>have an explicit string datatype.
><property name="foo">
>   <string value="hello"/>

I was thinking that we could still shortcut it aswell.

ie <property name="foo" value="hello" /> is equivelent to above. However
<property name="foo" value="${myfileset}" /> would actually assign foo a
FileSet object (assuming ${myfileset} evaluated to a FileSet).

>A little verbose at first glance, compared with the current usage. In
>any case, we are also going to need to decide the future of the ${}
>syntax (too late to change it, IMHO) 

I agree. In most of my stuff where I evaluate properties I allow things like


if type=native then it would evaluate to "${}" and then evaluate
that again. However I explictly removed it fro latest proposal because I
thought it was way too complex ... or potentially. Thou it is damn useful -
not sure.

>and what it would mean for
>non-string properties (equivalent to toString() method, perhaps)

yep. See my latest proposal for what I think on that .

>> This kinda functionality would be useful for certain
>> specialized areas.
>Can you elaborate?

Most of the time it is when I want to store some "semi"-persistent data
throughout the build process. A while back I integrated with a very ancient
unit testing framework. I had to keep running no matter what and collect
all the results in a specific format and do specific things with them. 

ie tests1-10 could be ignored if failed while tests 13-15 indicate the
authours need to be emailed etc. I ended up having to write stuff out
filesystem and read it back in later - or translate to string and then
interpret it later. It would be nicer if didn't have to go through this
extra stage but instead could place ReultSet data types into property.

Theres a few other similar cases I have come across thou they all revolve
around keeping some data persistent over build process that is not strings.



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message