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=10399>. 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=10399 Merge <waitfor> and <condition> Summary: Merge <waitfor> and <condition> Product: Ant Version: unspecified Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Well, this is a minor issue, I admit, but for the sake of conceptional beauty, I would vote for a merge of the conditions/tasks <waitfor> and <condition>. Why not use <condition> and add the attributs from the <waitfor> task to it? My reasoning for this: - in a literal sense, a condition is s.th that one can wait for to become true or false. - the word condition is declarative, waitfor is imperative. The ant/xml approach is a declarative approach, therefore <condition> fits better. - I would not invent a separate task just to factor out timout issues from the condition task. - The waitfor task seems to subsum the condition task. Anything that I could do with the condition task, i could also do with the waitfor task but not the other way round. Therefore, one task would do. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
