ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eugene Voytitsky <...@sunbay.com>
Subject Re[2]: <pathconvert> in 1.5beta3
Date Thu, 27 Jun 2002 15:50:45 GMT
Hello Diane,

DH> I made that change because the earlier behaviour required you to do a:
DH>       <condition property="is.empty">
DH>         <equals arg1="${prop.set.by.pathconvert}" arg2=""/>
DH>       </condition>
DH> then use "is.empty" as the determining property to do/not do things,
DH> instead of being able to just use the property that <pathconvert>
DH> sets(/doesn't set) directly.

Yes, in this case new behavior is more convenient.
But it breaks down targets which use <pathconvert> for
displaying list of files (with pathsep="${line.separator}" e.g.)
and ask user about confirmation (with <input>).
It's pity.

DH> That not only seemed like a royal PITA, but
DH> it also seemed like a bug to me that <pathconvert> would set a property
DH> regardless of whether it had a value, since no other task that sets a
DH> property will set it regardless (other than <property> itself, with the
DH> user setting the value explicitly to "").

It makes sense, I agree...
It would be great if it was clear documented in JavaDocs.

>> BTW right behavior in this case isn't explicitly specified in docs,
>> but I guess that old behavior is more correct. Isn't it?
DH> Why do you think it's more correct the old way?

My fine-worked scripts don't work now :))
All my other arguments disappeared after your comments.

DH> What advantage does it
DH> offer that the new behaviour doesn't?

see above (displaying + <input>)

-- 
Best regards,
Eugene Voytitsky                            mailto:viy@sunbay.com


--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message