[jira] [Commented] (AXIS2-5871) Cannot deploy Service by .aar on Windows

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16140945#comment-16140945
 ] 

Hudson commented on AXIS2-5871:
---

SUCCESS: Integrated in Jenkins build axis2-1.7 #134 (See 
[https://builds.apache.org/job/axis2-1.7/134/])
AXIS2-5871: Merge r1806088 to the 1.7 branch. (veithen: rev 1806103)
* (edit) axis2
* (edit) 
axis2/modules/kernel/src/org/apache/axis2/deployment/ServiceDeployer.java


> Cannot deploy Service by .aar on Windows
> 
>
> Key: AXIS2-5871
> URL: https://issues.apache.org/jira/browse/AXIS2-5871
> Project: Axis2
>  Issue Type: Bug
>Affects Versions: 1.7.6
>Reporter: Dmitry Smeliansky
>
> Similar to AXIS2-5778:
> org.apache.axis2.deployment.ServiceDeployer.deployFromUrl uses wrong 
> separator for building the service name from URL



--
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

Jenkins build is back to normal : axis2-1.7 #134

[Apache Jenkins Server]

See 


-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

Jenkins build is back to normal : axis2-1.7 » jmsService #134

[Apache Jenkins Server]

See 



-
To unsubscribe, e-mail: java-dev-unsubscr...@axis.apache.org
For additional commands, e-mail: java-dev-h...@axis.apache.org

[jira] [Updated] (AXIS2-5870) XMLPrettyPrinter.prettify uses OS-dependant newlines

[Andreas Veithen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Veithen updated AXIS2-5870:
---
Fix Version/s: 1.7.7

> 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
> Fix For: 1.7.7
>
> Attachments: AXIS2-5870 generated.xsd.patch, AXIS2-5870 
> InMemory-prettify.patch, 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. 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:
> {CODE}
> transformer.setOutputProperty("{http://xml.apache.org/xalan}line-separator","\n;);
> {CODE}
> or
> {CODE}
> 
> {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 

[jira] [Commented] (AXIS2-5870) XMLPrettyPrinter.prettify uses OS-dependant newlines

[Andreas Veithen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16140709#comment-16140709
 ] 

Andreas Veithen commented on AXIS2-5870:


Can you test this with the latest code from the 1.7 branch?

> 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: AXIS2-5870 generated.xsd.patch, AXIS2-5870 
> InMemory-prettify.patch, 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. 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:
> {CODE}
> transformer.setOutputProperty("{http://xml.apache.org/xalan}line-separator","\n;);
> {CODE}
> or
> {CODE}
> 
> {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 

Build failed in Jenkins: axis2-1.7 #133

[Apache Jenkins Server]

See 

Changes:

[veithen] AXIS2-5781, AXIS2-5870: Merge r1779069 and r1779074 to the 1.7 branch.

--
[...truncated 3.35 MB...]
[JENKINS] Archiving 

 to 
org.apache.axis2/axis2-soapmonitor-servlet/1.7.7-20170824.203201-4/axis2-soapmonitor-servlet-1.7.7-20170824.203201-4.jar
[JENKINS] Archiving 

 to 
org.apache.axis2/axis2-soapmonitor-servlet/1.7.7-20170824.203201-4/axis2-soapmonitor-servlet-1.7.7-20170824.203201-4-sources.jar
[JENKINS] Archiving 

 to 
org.apache.axis2/axis2-soapmonitor-servlet/1.7.7-20170824.203201-4/axis2-soapmonitor-servlet-1.7.7-20170824.203201-4-javadoc.jar
[JENKINS] Archiving 

 to 
org.apache.axis2.examples/jaxws-interop/1.7.7-SNAPSHOT/jaxws-interop-1.7.7-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.axis2.examples/jaxws-interop/1.7.7-SNAPSHOT/jaxws-interop-1.7.7-SNAPSHOT.jar
[JENKINS] Archiving 

 to 
org.apache.axis2.examples/jaxws-interop/1.7.7-SNAPSHOT/jaxws-interop-1.7.7-SNAPSHOT-sources.jar
[JENKINS] Archiving 

 to 
org.apache.axis2.examples/jaxws-interop/1.7.7-SNAPSHOT/jaxws-interop-1.7.7-SNAPSHOT-javadoc.jar
[JENKINS] Archiving 
 to 
org.apache.axis2/axis2-corba/1.7.7-SNAPSHOT/axis2-corba-1.7.7-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.axis2/axis2-corba/1.7.7-20170824.202532-4/axis2-corba-1.7.7-20170824.202532-4.jar
[JENKINS] Archiving 

 to 
org.apache.axis2/axis2-corba/1.7.7-20170824.202532-4/axis2-corba-1.7.7-20170824.202532-4-sources.jar
[JENKINS] Archiving 

 to 
org.apache.axis2/axis2-corba/1.7.7-20170824.202532-4/axis2-corba-1.7.7-20170824.202532-4-javadoc.jar
[JENKINS] Archiving 
 to 
org.apache.axis2/org.apache.axis2.osgi/1.7.7-SNAPSHOT/org.apache.axis2.osgi-1.7.7-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.axis2/org.apache.axis2.osgi/1.7.7-20170824.203125-4/org.apache.axis2.osgi-1.7.7-20170824.203125-4.jar
[JENKINS] Archiving 

 to 
org.apache.axis2/org.apache.axis2.osgi/1.7.7-20170824.203125-4/org.apache.axis2.osgi-1.7.7-20170824.203125-4-sources.jar
[JENKINS] Archiving 

 to 
org.apache.axis2/org.apache.axis2.osgi/1.7.7-20170824.203125-4/org.apache.axis2.osgi-1.7.7-20170824.203125-4-javadoc.jar
[JENKINS] Archiving 

 to 
org.apache.axis2.examples/jaxws-addressbook/1.7.7-SNAPSHOT/jaxws-addressbook-1.7.7-SNAPSHOT.pom
[JENKINS] Archiving 

 to 
org.apache.axis2.examples/jaxws-addressbook/1.7.7-SNAPSHOT/jaxws-addressbook-1.7.7-SNAPSHOT.jar
[JENKINS] Archiving 

 to 
org.apache.axis2.examples/jaxws-addressbook/1.7.7-SNAPSHOT/jaxws-addressbook-1.7.7-SNAPSHOT-sources.jar
[JENKINS] Archiving 

 to 
org.apache.axis2.examples/jaxws-addressbook/1.7.7-SNAPSHOT/jaxws-addressbook-1.7.7-SNAPSHOT-javadoc.jar
[JENKINS] Archiving 

[jira] [Commented] (AXIS2-5870) XMLPrettyPrinter.prettify uses OS-dependant newlines

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16140698#comment-16140698
 ] 

Hudson commented on AXIS2-5870:
---

FAILURE: Integrated in Jenkins build axis2-1.7 #133 (See 
[https://builds.apache.org/job/axis2-1.7/133/])
AXIS2-5781, AXIS2-5870: Merge r1779069 and r1779074 to the 1.7 branch. 
(veithen: rev 1806081)
* (edit) axis2
* (edit) 
axis2/modules/codegen/test/org/apache/axis2/wsdl/codegen/writer/SchemaWriterTest.java
* (edit) 
axis2/modules/kernel/test/org/apache/axis2/description/java2wsdl/XMLSchemaTest.java


> 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: AXIS2-5870 generated.xsd.patch, AXIS2-5870 
> InMemory-prettify.patch, 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. 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:
> {CODE}
> transformer.setOutputProperty("{http://xml.apache.org/xalan}line-separator","\n;);
> {CODE}
> or
> {CODE}
> 
> {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 

[jira] [Commented] (AXIS2-5781) Maven Build - Module: kernel - generates / modifies file under source-control - should build in output directory

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-5781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16140697#comment-16140697
 ] 

Hudson commented on AXIS2-5781:
---

FAILURE: Integrated in Jenkins build axis2-1.7 #133 (See 
[https://builds.apache.org/job/axis2-1.7/133/])
AXIS2-5781, AXIS2-5870: Merge r1779069 and r1779074 to the 1.7 branch. 
(veithen: rev 1806081)
* (edit) axis2
* (edit) 
axis2/modules/codegen/test/org/apache/axis2/wsdl/codegen/writer/SchemaWriterTest.java
* (edit) 
axis2/modules/kernel/test/org/apache/axis2/description/java2wsdl/XMLSchemaTest.java


> Maven Build - Module: kernel - generates / modifies file under source-control 
> - should build in output directory
> 
>
> Key: AXIS2-5781
> URL: https://issues.apache.org/jira/browse/AXIS2-5781
> Project: Axis2
>  Issue Type: Bug
>  Components: kernel
>Affects Versions: 1.7.3
>Reporter: Jeff Thomas
>Priority: Minor
>
> Maven Build for axis2-kernel (./modules/kernel/pom.xml).
> In the axis2-kernel Maven Module (and at in at least the axis2-integration 
> module as well) test ant-scripts and unit-tests run against the 
> "./test-resources" directory instead of the "./target/test-resources" 
> directory.
> In the interest of Maven "compliance" the build process should not edit, 
> touch or otherwise "dirty" source-code files.
> Examples:
> 1.  The Ant-script "test-resources/deployment/service2/build.xml" creates 
> temporary directories, generates content, and removes these temporary 
> directories directly within the "test-resources" source directory.
> 2. The Unit-Test utility method 'readWSDLFromFile' in XMLSchemaTest creates a 
> File reference to a file in "test-resources" and performs the following:
> {code:java}XMLPrettyPrinter.prettify(file);{code}
> This updates (dirties) the input source-file - on my windows build it changes 
> the line-endings from Unix to Windows.
> The current Maven POMs already take care of copying the "test-resources" 
> directory to "target/test-resources" so all of the required input files and 
> ant-scripts are available there.  Therefore, the POM ANT "dir" properties and 
> the JUnit tests just need to be updated to use these instead of the 
> source-code originals.



--
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

Build failed in Jenkins: axis2-1.7 » jmsService #133

[Apache Jenkins Server]

See 


--
[INFO] 
[INFO] 
[INFO] Building jmsService 1.7.7-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.2:clean (default-clean) @ jmsService ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.1:enforce (default) @ jmsService ---
[INFO] 
[INFO] --- gmavenplus-plugin:1.5:execute (create-tmp-directory) @ jmsService ---
[INFO] Using Groovy 2.4.4 to perform execute.
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-resource-bundles) 
@ jmsService ---
[INFO] 
[INFO] --- maven-resources-plugin:2.4.2:resources (default-resources) @ 
jmsService ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.5.1:compile (default-compile) @ jmsService 
---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to 

[INFO] 
[INFO] --- maven-resources-plugin:2.4.2:testResources (default-testResources) @ 
jmsService ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @ 
jmsService ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.13:test (default-test) @ jmsService ---
[JENKINS] Recording test results
[INFO] 
[INFO] --- maven-jar-plugin:2.2:jar (default-jar) @ jmsService ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-site-plugin:3.6:attach-descriptor (attach-descriptor) @ 
jmsService ---
[INFO] Skipping because packaging 'jar' is not pom.
[INFO] 
[INFO] --- maven-assembly-plugin:2.6:single (source-release-assembly) @ 
jmsService ---
[INFO] Assemblies have been skipped per configuration of the skipAssembly 
parameter.
[INFO] 
[INFO] --- maven-source-plugin:2.4:jar-no-fork (source-jars) @ jmsService ---
[INFO] Building jar: 

[INFO] 
[INFO] --- maven-javadoc-plugin:2.10.3:jar (attach-javadocs) @ jmsService ---
[INFO] 
Loading source files for package org.apache.axis2.examples.jmsservice...
Constructing Javadoc information...
Standard Doclet version 1.8.0_144
Building tree for all the packages and classes...
Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Generating 

Building index for all the packages and classes...
Generating 

Generating 

Generating 

Building index for all classes...
Generating 

Generating 

Generating 

Generating 

[jira] [Commented] (AXIS2-5870) XMLPrettyPrinter.prettify uses OS-dependant newlines

[Andreas Veithen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16140570#comment-16140570
 ] 

Andreas Veithen commented on AXIS2-5870:


This issue actually partially duplicates AXIS2-5781 and has been fixed by 
r1779069 and r1779074 on the trunk, so we could just merge these two changes to 
the 1.7 branch.

> 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: AXIS2-5870 generated.xsd.patch, AXIS2-5870 
> InMemory-prettify.patch, 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. 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:
> {CODE}
> transformer.setOutputProperty("{http://xml.apache.org/xalan}line-separator","\n;);
> {CODE}
> or
> {CODE}
> 
> {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 

[jira] [Updated] (AXIS2-5870) XMLPrettyPrinter.prettify uses OS-dependant newlines

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AXIS2-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Schöning updated AXIS2-5870:
-
Attachment: AXIS2-5870 generated.xsd.patch

"custom_schemas/generated.xsd" was not read by "readWSDLFromFile" and therefore 
not covered by the former fix to work in memory only. So I added an additional 
implementation in SchemaWriter allowing to serialize into memory only and use 
that result to compare schemas.

> 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: AXIS2-5870 generated.xsd.patch, AXIS2-5870 
> InMemory-prettify.patch, 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. 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:
> {CODE}
> transformer.setOutputProperty("{http://xml.apache.org/xalan}line-separator","\n;);
> {CODE}
> or
> {CODE}
> 
> {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}
> 

[jira] [Updated] (AXIS2-5871) Cannot deploy Service by .aar on Windows

[Dmitry Smeliansky (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2-5871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Smeliansky updated AXIS2-5871:
-
Affects Version/s: 1.7.6

> Cannot deploy Service by .aar on Windows
> 
>
> Key: AXIS2-5871
> URL: https://issues.apache.org/jira/browse/AXIS2-5871
> Project: Axis2
>  Issue Type: Bug
>Affects Versions: 1.7.6
>Reporter: Dmitry Smeliansky
>
> Similar to AXIS2-5778:
> org.apache.axis2.deployment.ServiceDeployer.deployFromUrl uses wrong 
> separator for building the service name from URL



--
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

[jira] [Created] (AXIS2-5871) Cannot deploy Service by .aar on Windows

[Dmitry Smeliansky (JIRA)]

Dmitry Smeliansky created AXIS2-5871:


 Summary: Cannot deploy Service by .aar on Windows
 Key: AXIS2-5871
 URL: https://issues.apache.org/jira/browse/AXIS2-5871
 Project: Axis2
  Issue Type: Bug
Reporter: Dmitry Smeliansky


Similar to AXIS2-5778:
org.apache.axis2.deployment.ServiceDeployer.deployFromUrl uses wrong separator 
for building the service name from URL



--
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

[jira] [Updated] (AXIS2-5870) XMLPrettyPrinter.prettify uses OS-dependant newlines

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AXIS2-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Schöning updated AXIS2-5870:
-
Attachment: AXIS2-5870 InMemory-prettify.patch

This is a patch implementing prettify in memory only.

> 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: AXIS2-5870 InMemory-prettify.patch, 
> 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. 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:
> {CODE}
> transformer.setOutputProperty("{http://xml.apache.org/xalan}line-separator","\n;);
> {CODE}
> or
> {CODE}
> 
> {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 

[jira] [Updated] (AXIS2-5870) XMLPrettyPrinter.prettify uses OS-dependant newlines

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AXIS2-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Schöning updated AXIS2-5870:
-
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:

{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. 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:

{CODE}
transformer.setOutputProperty("{http://xml.apache.org/xalan}line-separator","\n;);
{CODE}
or
{CODE}

{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. 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/

{QUOTE}
/*
 * $Id: TransformerImpl.java,v 1.167 2005/07/15 22:21:30 mcnamara Exp $
 */
[...]
   * The recognized Xalan extension elements are: 
   * 
   * content-handler
   * entities
   * indent-amount
   * line-separator
   * omit-meta-tag
   * use-url-escaping
   * 
{QUOTE}

{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

[jira] [Updated] (AXIS2-5870) XMLPrettyPrinter.prettify uses OS-dependant newlines

[JIRA]

 [ 
https://issues.apache.org/jira/browse/AXIS2-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thorsten Schöning updated AXIS2-5870:
-
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:

{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}

{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. 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/

{QUOTE}
/*
 * $Id: TransformerImpl.java,v 1.167 2005/07/15 22:21:30 mcnamara Exp $
 */
[...]
   * The recognized Xalan extension elements are: 
   * 
   * content-handler
   * entities
   * indent-amount
   * line-separator
   * omit-meta-tag
   * use-url-escaping
   * 
{QUOTE}

{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 

[jira] [Created] (AXIS2-5870) XMLPrettyPrinter.prettify uses OS-dependant newlines

[JIRA]

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}

{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