DO NOT REPLY [Bug 10399] New: - Merge and

[bu...@apache.org]

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: ant-dev@jakarta.apache.org
        ReportedBy: wtff@freenet.de


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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>