Hi,
while looking into the ant-contrib test failures in Gump I revisited our logging system for the first time since long.
Consider I have a task that does log("Some message\n"). Project#fireMessageLogged() will then strip the \n (at leat on Unix) and DefaultLogger will re-add it for the output.
AntTestListener in turn will not add a new-line but simply concatenate all log output into a StringBuffer.
If I now say assertLogContaining("Some message\n") it fails. Should it? Yes, I know, I shouldn't use \n in my log message in the first place, but still.
Now say I'm doing
log("line1"); log("line2");
in the task. I have to assert that the log contains "line1line2" right now, which is rather ugly and unreadable. Again, should it be that way?
I'd go for including \n into the tests, with caveats. The risk is not that Ant's own tasks break -whcih we can fix-, but that third party ant tasks tests break. We've never made guarantees of ant-testutils.jar being consistent, but third party projects will want to be able to build against both 1.6 and 1.7 ant, so dont wan't a gratuitous break.
Why not put the change in and we'll see what breaks in terms of ant-contrib and others.
What I prefer, incidentally, is for tasks to declare strings as constants and then you refer to them in the test...I write all my tests that way, because it stops my tests being so brittle to change.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
