Incorrectly formats XML files with DOCTYPE statements about xml-formatter HOT 10 CLOSED

First, it's not immediately obvious how I start using this new xml-formatter project. Do I just need to use the latest version of the formatter-maven-plugin plugin?

Using the latest formatter-maven-plugin is probably the most common way to use it. However, you could also create an instance of new XmlDocumentFormatter(...).format(...) to use it directly in your code.

from xml-formatter.

I guess this may be entirely a jsoup problem, without a known solution? https://stackoverflow.com/questions/31164415/how-to-preserve-doctype-declarations-when-manipulating-xml-with-jsoup

from xml-formatter.

from xml-formatter.

@hinchliff I quickly ran a test with a doctype xml using the new formatter and things look good, maybe you can give it a shot and confirm. @hazendaz since the ticket is pretty old perhaps we can close it and let XML specific issues be open on the xml-formatter repo?

from xml-formatter.

I'm not involved with that project anymore, but I took a quick look anyway.

First, it's not immediately obvious how I start using this new xml-formatter project. Do I just need to use the latest version of the formatter-maven-plugin plugin?

Unfortunately that resulted in some SAXParserException on this (orca5) project:

[ERROR] Failed to execute goal net.revelc.code.formatter:formatter-maven-plugin:2.9.0:format (default-cli) on project orca: Execution default-cli of goal net.revelc.code.formatter:formatter-maven-plugin:2.9.0:format failed: org.xml.sax.SAXParseException; lineNumber: 9; columnNumber: 2; The markup in the document following the root element must be well-formed. -> [Help 1]

The error message doesn't tell you which file caused the error, but turning on maven debugging (-X) seems to indicate that it was processing orca5/blob/master/boot/ant/deps.xml, although I don't see any obvious errors in that file.

from xml-formatter.

The xml-formatter uses a SAXParser to validate the XML is well formed before trying to format it. Not sure about the error pointing to line 9 column 2, but boot/ant/deps.xml seems to me like invalid XML since it does not have a root element. So that's very interesting and not sure how we would deal with this or if we should.

from xml-formatter.

There's a similar problem in impsort-maven-plugin, where it fails to sort imports if the Java code isn't valid. So far, I've chosen to not fix the problem... and just tell people that valid Java is a prerequisite.

However, for XML, I think it might be a common thing for config files to be "snippets" of XML, rather than full XML. I think the question here is whether this formatter should also format such snippets. If so, maybe it can try to catch the exception, wrap with a dummy root element, re-try to format, and then strip out the dummy root element that was inserted?

from xml-formatter.

Having the plugin fail with an error may not be the best solution, when previous versions of the plugin would run to completion without even a warning.

It might be reasonable to catch the exception and print a warning before skipping the file.

It's not clear to me what if anything previous versions (2.6.0) of the plugin did or attempted to do for this file, all the debug log says is:

Nothing formatted. Try to fix line endings.

from xml-formatter.

Interestingly enough as I understand it this is a valid Ant configuration file (never dealt with Ant before), and the original formatter was for Ant. So it's worth noting that I introduced the SAXParser when refactoring code, without that well formed check the file is processed fine.

So while the original implementation does not check for valid XML it does suppress any errors and just copies tags as-is, see here. I suppose this is fine and probably a desired over failure, only downside being that it would not serve a developer to catch invalid XMLs whereas for example malformed Java would be caught in compilation, but that's more along the lines of the default XML formatter in Eclipse anyway.

So all in all I'm OK with removing the SAX validation if you guys agree.

from xml-formatter.

Could make the SAX validation optional, with different modes: "FAIL, WARN, IGNORE"

from xml-formatter.