Le 21 avr. 2011 à 23:26, Nicolas Lalevée a écrit : > > Le 21 avr. 2011 à 18:48, Antoine Levy-Lambert a écrit : > >> 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 data. >> >> 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 ? > > I guess this is showing another bug in the streams setup. Since the only > change you did was about the case where streams get funneled, I am surprised > that the streams are funneled when the output is redirected to a property. It > would mean that we could catch the bytes from the error stream in the output > property. So maybe the condition on the line 720 of Redirector is incorrect. > I'm sure though what should be there instead.
I've looked deeper into this and I have found a solution. See r1097261 [1]. I somehow followed the documentation about the attribute "logError" on the java task [2] which says: "If you redirect error with the "error" or "errorProperty" attributes, this will have no effect."; I understand this as if there is a redirect of the error streams, they should not be mixed up. Which makes sense to me. Nicolas [1] http://svn.apache.org/viewvc?view=revision&revision=1097261 [2] http://ant.apache.org/manual/Tasks/java.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
