DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11585>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11585 The Replace Task ignores properties with multiline replacements ------- Additional Comments From [EMAIL PROTECTED] 2003-08-01 06:36 ------- Maybe we should be having this discussion on the dev list? Anyway, there are three potential problems I see if we change addText to auto-expand properties: (1) is what Antoine writes. Even though I think it's unlikely, it can happen. (2) Tasks that perform property expansion themselves will now double-expand properties. If the value of a is ${b} (for whatever reason) then <echo>${a}</echo> would suddenly resolve b if possible. We would certainly change all our own tasks, but what about third-party tasks. I don't think this is a high risk either, as the result will only change if b has been set, but something to think of. (3) My most important issue: If I write a task that is supposed to work with Ant 1.5 as well as 1.6 and I want property expansion for nested text, I'll either have to write two versions of it or detect Ant's version at run time to know whether I need to expand the properties myself. This is rather ugly. If we add a new introspection point we should probably give the new method precedence over addText so that a task can have both - expand properties in addText and not do so in the new method. That way you can easily have backwards compatibility, even at the API level of our tasks. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
