Details
Minor Description
I'm building version 1.7.6 on Windows checked out using SVN by simply running "mvn install" and recognized that after running a successful build some WSDL and XSD files in my working copy have changed. TortoiseSVN is saying that the only differences in those files are newlines. Two things are interesting here: 1. It's not all WSDLs and XSDs, only very few. 2. It's not all newlines within the files which get changed, so the result actually is an inconsistent mix of Unix and Windows newlines. The changed files are the following:
modules/codegen/test-resources/schemas/custom_schemas/generated.xsd
modules/kernel/test-resources/wsdl/printWSDLreference.wsdl
modules/kernel/test-resources/wsdl/testGenerateInterfaceOperationElement11_WSDL.wsdl
modules/kernel/test-resources/wsdl/testGenerateInterfaceOperationElement_WSDL.wsdl
I'm attaching a screenshot where you can see that the license information keeps it's newlines, while the XML itself is changed to get Windows newlines. "keeps" is actually wrong, though, because during my tests I changed the file to Windows newlines only, executed a build and the newlines of the license text only were actually changed back to be Unix style.
So it seems that whatever is changing those files, it actively sets the newlines of the license text to Unix style and that of the XML to Windows style.
What seems to be responsible is XMLPrettyPrinter.prettify, because all the files changed are going through that function, either directly or using XMLSchemaTest.readWSDLFromFile:
public String readWSDLFromFile(String path) throws Exception { File file=new File(path); XMLPrettyPrinter.prettify(file); //this is used to correct unnecessary formatting in the file return readFile(path); }
If I simply remove all the code in XMLPrettyPrinter.prettify, all changed files are kept as they are. That means by default they keep their Unix style newlines and if I change the files to have Windows style newlines they keep those. So it really seems that only prettify is introducing the changes I see. Without prettify the newlines are as placed in the file and always consistent.
From my point of view running tests or such shouldn't change files under version control at all and it seems that most likely it isn't. Else it's unnecessary difficult to distinguish those changes from those one is making during development. So I would like to suggest to simply remove changing the files itself in readWSDLFromFile. It's even very unexpected that a method named "read" writes the file before... The applied prettify can easily work in memory only if really needed. The other approach would be to make sure that all platforms use the same consistent newlines, which is a bit difficult for some unknown reason...
As prettify already relies on Xalan, the latter in theory should easily possible by setting the newline character to use:
transformer.setOutputProperty("{http://xml.apache.org/xalan}line-separator","\n");
or
<xsl:output xalan:line-separator=" " />
https://stackoverflow.com/a/12278483/2055163
Tried that dozen of times, but for some reason it is not working as expected, the newline still is Windows style for the XML. I even tried using "___" and such nonsense as line separator and in theory that should work as well, but didn't. So it seems like the statement itself is ignored for some reason OR there's some other thing going on after Xalan which introduces the Windows style newlines. Remember that removing the code in prettify fixes the problem, so it must be something in there. Xalan itself is working fine, because the following is properly applied to the XML:
xalan:indent-amount='4'
vs.
xalan:indent-amount='40'
"line-separator" has been introduced in Xalan 2.7.0, because the associated bug has been resolved "02/Jun/05 06:18" and 2.7.0 has been published in "2005-08-08 04:26". The JDK I'm using provides Xalan 2.7.0 as well, so in theory everything should work. I've even downloaded the 2.7.0 source to check if the necessary code is present, it is.
https://issues.apache.org/jira/browse/XALANJ-2093
http://archive.apache.org/dist/xml/xalan-j/
/*
- $Id: TransformerImpl.java,v 1.167 2005/07/15 22:21:30 mcnamara Exp $
*/
[...]- The recognized Xalan extension elements are:
- <ul>
- <li>content-handler
- <li>entities
- <li>indent-amount
- <li>line-separator
- <li>omit-meta-tag
- <li>use-url-escaping
- </ul>
C:\Users\tschoening>"C:\Program Files\Java\jdk1.7\bin\java" com.sun.org.apache.xalan.internal.xslt.EnvironmentCheck
#---- BEGIN writeEnvironmentReport($Revision: 1.10 $): Useful stuff found: ----
java.version=1.7.0_80
version.xalan2x=not-present
version.JAXP=1.4
java.ext.dirs=C:\Program Files\Java\jdk1.7\jre\lib\ext;C:\WINDOWS\Sun\Java\lib\ext
version.SAX=2.0
version.crimson=not-present
java.class.path=.
version.ant=not-present
sun.boot.class.path=C:\Program Files\Java\jdk1.7\jre\lib\resources.jar;C:\Program Files\Java\jdk1.7\jre\lib\rt.jar;C:\Program Files\Java\jdk1.7\jre\lib\sunrsasign.jar;C:\Program Files\Java\jdk1.7\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.7\jre\lib\jce.jar;C:\Program Files\Java\jdk1.7\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.7\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.7\jre\classes
version.DOM=3.0
version.xalan1=not-present
version.xalan2_2=Xalan Java 2.7.0
version.xerces2=Xerces-J 2.7.1
version.xerces1=not-present
#----- END writeEnvironmentReport: Useful properties found: -----
# YAHOO! Your environment seems to be OK.
Not sure if it's worth investigating this further instead of simply removing rewriting the files and let prettify work in memory only.
