Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
1.0-Release
-
None
-
None
-
Operating System: other
Platform: PC
-
20992
Description
Ant test fails on Windows (specifically ant test-encoding) due to a problem
matching newlines between the result of parsing "encodingtest2.vm" and the
expected result "encodingtest2.cmp".
Apparently, WinCVS translates Unix newline (LF) to the Windows newline (CR LF)
when checking out the files. But the file "encodingtest2.cmp" already has
newlines in the windows format CR LF. When it's checked out to a Win machine,
this turns into CR CR LF. The result file (generated by the Velocity test),
generates CR LF for newline.
According to the Java Spec, the unusual case of CR CR LF should be treated as
a single newline [1], along with CR LF and LF. The Velocity test is smart
enough to normalize newlines (to make CR LF the same as LF). But does not
treat CR CR LF as a newline. Thus the compare file doesn't match the result
file and the test fails.
Got all that?
One solution would be to use CygWin CVS, which preserves the Unix newline
(LF), or check the box in WinCVS "Checkout files with the Unix LF".
A better solution is to change the routine in Velocity test
(normalizeNewlines) that normalizes the newlines, to treat the following as
equivalent newlines LF (unix), CR LF (win), and CR CR LF (win mistranslated).
The one-line patch is attached,
WILL
[1]
http://java.sun.com/docs/books/jls/second_edition/html/lexical.doc.html#231571