ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: Is BuildFileTest$AntTestListener doing the right thing?
Date Wed, 09 Mar 2005 10:50:38 GMT
Stefan Bodewig wrote:
> 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:
For additional commands, e-mail:

View raw message