If I'm not mistaken, Ant only outputs a verbose-level message to the build log when a file, that is specified using the "file" attribute, does not exist. When a directory that is specified using the "dir" attribute does not exist, no message whatsoever is output to the build log.
What the "quiet" attribute seems to do is (correct me if I'm wrong) :
- no longer have the task fail when a file/directory that is matched by a fileset cannot be deleted (not just when it doesn't exist) - output the cause of a failure using a verbose-level message instead of using a warning level
I'd have to look at the source to confirm this... I'm not running Ant in verbose mode, and I'm only deleting files :-P It wouldn't surprise me if you're right, though.
What we should do is :
- only output a verbose-level message when the file / directory pointed to by the "file" or "dir" attribute does not exist. Never fail the task if a file or directory specified using the "file"/"dir" attribute does not exist. This would match the behavior of Ant, except for the fact that Ant does not output any message when the directory pointed to by the "dir" attribute does not exist. This can be changed for the 0.85 release, and documented as a breaking change.
Sounds good, except for the never failing... I'd still lean towards failing if the file/directory doesn't exist, because it will catch typos that otherwise might be difficult to track down. Perhaps an attribute 'failonnomatches' (fail on no matches... there has to be a more readable name?!) which would suppress the failure with no warning if the file doesn't exist, but fail if the file exists but can't be deleted - as opposed to 'failonerror' which would print a warning if the file doesn't exist.
Or am I being too fail-safe paranoid?
- add support for either a threshold or loglevel attribute to tasks (or both) after the 0.85 release. This will allow build authors to control build output on a task-level in a generic way, instead of introducing such a mechanism for specific tasks.
I would suggest that it would be more useful (in general) to specify logging levels declaratively... that is, to specify an xml file (for example) which defines the thresholds and/or loglevels for each task; this could also be set through a task, then the configuration mechanism could be an included build file.
Then again, I can see the point of task instance level log filtering, if you want to suppress logging for just a single task, but not for other instances of the same task in the build... would it be excessive to include both?
-- Troy
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
