Thorsten Schöning created AXIS2-5870:
----------------------------------------
Summary: XMLPrettyPrinter.prettify uses OS-dependant newlines
Key: AXIS2-5870
URL: https://issues.apache.org/jira/browse/AXIS2-5870
Project: Axis2
Issue Type: Bug
Components: kernel
Affects Versions: 1.7.6
Environment: Windows 10 Pro x86-64, JDK 1.7.0_80
Reporter: Thorsten Schöning
Priority: Minor
Attachments: printWSDLreference.wsdl.png
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:
{CODE}
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);
}
{CODE}
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. 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:
{CODE}
transformer.setOutputProperty("{http://xml.apache.org/xalan}line-separator","\n";);
{CODE}
or
{CODE}
<xsl:output xalan:line-separator=" " />
{CODE}
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:
{CODE}
xalan:indent-amount='4'
{CODE}
vs.
{CODE}
xalan:indent-amount='40'
{CODE}
"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.
https://issues.apache.org/jira/browse/XALANJ-2093
http://archive.apache.org/dist/xml/xalan-j/
{QUOTE}
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.
{QUOTE}
Not sure if it's worth investigating this further instead of simply removing
rewriting the files and let prettify work in memory only.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org
