...Regarding the last section about the XML-parser sending af single '\n' - I belive that from at least XML 1.1 it is mandatory for XML-parsers to send a single '\n' up to applications disregarding platform and actual EOL-marker within input-files parsed (with the purpose of simplifying processing within applications, I believe) - perhaps the existing parser already does this...
Just a thought, have no idea if it applies here. Regards, Morten Sabroe Mortensen -----Original Message----- From: Antoine Lévy-Lambert [mailto:[EMAIL PROTECTED] Sent: 23. september 2003 12:23 To: Ant Developers List Subject: ReplaceTest failing under cygwin ReplaceTest fails under cygwin. [junit] Testcase: test9 took 0,13 sec [junit] FAILED [junit] expected:<10> but was:<13> [junit] junit.framework.AssertionFailedError: expected:<10> but was:<13> This has to do with the fact that the Replace task changes the line endings of tokens and values to System.getProperty("line.separator"), but that the files used for the tests are terminated with \n only when one uses the cvs.exe of cygwin. I can think of several ways of fixing this : - the easiest would be to change the Replace task, not to touch the line endings of tokens and values at all. After all, I do not know why they get such a special treatment. But this would also be a backward incompatible change, - adding an enumerated attribute eol (like in the fixcrlf task) to the nested elements <replacetoken/>, <replacevalue/>, <replacefilter/>. Like in the fixcrlf task, the platform's line separator would be the default there, and "asis" would be used to run the test(s) with predictable results. Is the reason why line endings of tokens and values in <replace/> are manipulated that, when they are read from <!<[CDATA[, the xml parser sends to ant \n as line separator also on Windows, which is generally not what is desired ? When on the contrary the replacetoken or replacevalue come from a property, the build file writer is fully in control of the flavour of the line endings of the tokens and values and would not need any special manipulation. Cheers, Antoine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
