Hi Conor,
I am +1 on your changes.
> The Ant output handling now will pass every character through to the
> generating task without inserting line breaks at buffer full intervals.
Also
> line breaks will not be converted to the platform line separator.
>
> So, if a java application running on Windows writes \n and not \r\n, the
> output stream that gets redirected to an ouput file will not have \n\r.
It's
> not a big deal I think since the generating application should be in
control
> - it may really want to generate a Unix format output.
>
This is like changes which have been done to FileUtils#copyFile(File
sourceFile, File destFile,
FilterSetCollection filters, Vector filterChains,
boolean overwrite, boolean preserveLastModified,
String inputEncoding, String outputEncoding,
Project project)
by Peter Reilly and then a little bit by myself to make sure that line
endings are not changed by FilterSets or FilterChains.
The class TokenFilter.LineTokenizer (written by Peter Reilly) is the tool
which allows to read input line by line including the original line ending.
Actually, I wonder whether this class (LineTokenizer) should not be in its
own .java file to give it more visibility. Suggestion about the appropriate
package ( org.apache.tools.ant.util ?) and name (I think LineTokenizer is
very expressive, I would retain this).
Since it is new from 1.6, we can refactor this without breaking compat.
The optional task <translate/> is not yet using this tokenizer, I am
planning to change it too.
Then we can say that the general Ant philosophy in tasks or types
manipulating files or streams is to preserve line endings (except of course
<fixcrlf/> whose job is to change line endings).
Antoine
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
