ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Levy-Lambert <>
Subject Re: Log Flushing
Date Thu, 21 Apr 2011 16:48:49 GMT
I have dived in and committed the code attached to 50507, and also made
flush a no op in LineOrientedOutputStream. See my commits [1] and [2].
Something does not feel 100% right though. In the second commit I have
tweaked unit tests to deal with some consequences of having made flush a
no op.

see this [3]

Then the streams really get flushed when they are closed when no carriage return is in the

So if you send "foo", ant was able to redirect "foo" without ending carriage return.

In the new version the output of copying "foo" is "foo\n".

Is there a way to avoid that change of behavior ?




On 4/19/11 5:51 PM, Antoine Levy-Lambert wrote:
> I just created a test for the bug 50507. I did this one as JUnit, not
> AntUnit although it is similar in its form to AntUnit. The capturing
> of the output of the "ant" task did not seem to work when running all
> this in the context of antunit.
> Stefan might have an idea why ?
> Antoine
> On 4/19/2011 11:56 AM, Nicolas Lalevée wrote:
>> Le 19 avr. 2011 à 16:42, Antoine Levy-Lambert a écrit :
>>> On 4/19/2011 8:29 AM, Nicolas Lalevée wrote:
>>>> Thank you very much for the pointers. The patch for the bug report
>>>> #50507 seems to tackle the streaming issue.
>>>> I guess that in Ant we always want to see the log by line, rather
>>>> than with usual unix tools where the output is streamed. With unix
>>>> tools, streaming is useful when pipelining commands. I guess we
>>>> never do that with Ant.
>>>> In the suggested patch, line ending "awareness" is only enabled
>>>> when we merge both the standard output stream and the error one.
>>> I think the line ending awareness is enabled by the patch in the
>>> case when there is no redirection of either standard err or standard
>>> out to files or properties. I do not think it is the same as merging
>>> standard out and standard err, except that if a line of standard err
>>> is produced by the executable between two lines of standard out it
>>> will be visible that way.
>>> If one of the two stream, out and err, is not redirected to a file
>>> or copied to a property, lines should still be preserved, so other
>>> use cases should be changed functionally if currently they break lines.
>> Well, if the two streams are not merged, then there should not be any
>> issue then, as each stream will push things into its own "thing".
>> "thing" being a file, or a socket, or even a wrapped standard stream.
>> In that last case of the "wrapped standard stream", it is then the
>> responsibility of the wrapper to properly output it I think.
>> But as you pointed to me in the chat, there is indeed some issue with
>> the LineOrientedOutputStream which is quite sensible with too many
>> flush. It will create a new line on each flush.
>> I then suggest to make the LineOrientedOutputStream#flush function do
>> nothing, which will fix Conor's bug.
>> And the patch in #50507 will actually just fix the bug #50507.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message