Add configuration if the encoding of JIRA xml file is not UTF-8

Benjamin Bentmann added a comment - 24/Dec/08 3:19 AM XML has an encoding declaration, so a parameter on the plugin shouldn't be necessary. Can you attach the XML file downloaded by the plugin, i.e. {{$ {project.build.directory} /jira-results.xml}}. It's written using platform encoding and I suspect that's where it gets messed up.

Felipe Cuozzo added a comment - 16/Dec/09 9:11 AM Hi Benjamin, I step in the same problem here, running the plugin on Windows (pt_BR locale, ISO-8859-1 encoding). I was able to bypass this error setting the system property -Dfile.encoding=UTF-8 when running Maven2, so your comment about plataform encoding is probably right. I'll try to attach the generated files. Here is the stacktrace: WARNING: Going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended. org.apache.xerces.impl.io.MalformedByteSequenceException: Invalid byte 2 of 3- byte UTF-8 sequence. at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source) at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.parse(Unknown Source) at javax.xml.parsers.SAXParser.parse(SAXParser.java:331) at org.apache.maven.plugin.jira.JiraXML.<init>(JiraXML.java:66) at org.apache.maven.plugin.jira.JiraReportGenerator.<init>(JiraReportGenerator.java:93) at org.apache.maven.plugin.jira.JiraMojo.executeReport(JiraMojo.java:249) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:131) at org.apache.maven.plugin.changes.AbstractChangesReport.execute(AbstractChangesReport.java:172) And here is the GET respose from the Jira server: HTTP/1.0 200 OK Date: Wed, 16 Dec 2009 13:36:19 GMT Server: Apache Cache-Control: no-cache, no-store, must-revalidate Pragma: no-cache Expires: Wed, 31 Dec 1969 23:59:59 GMT Content-Type: text/xml;charset=ISO-8859-1 X-Cache: MISS from xxxx X-Cache-Lookup: MISS from xxxx:3128 Via: 1.0 pedra:3128 (squid/2.6.STABLE6) Proxy-Connection: close <!-- RSS generated by JIRA (Enterprise Edition, Version: 3.12.3-#302) at Wed Dec 16 11:36:19 BRST 2009 --> <!-- If you wish to do custom client-side styling of RSS, uncomment this :

Felipe Cuozzo added a comment - 16/Dec/09 9:21 AM I've zipped the files to avoid any corruption of the character encodings. Inside it you will find 2 files: jira-results.xml : is the file generate using the default plataform encoding. jira-results-forcing-UTF-8.xml : is the file generated when the -Dfile.encoding=UTF-8 system parameter was added to the Maven execution arguments.

Dennis Lundberg added a comment - 01/Jan/11 11:56 AM Fixed in r1054263 . A new 2.4-SNAPSHOT has been deployed. Please help us test it. I added a new configuration parameter jiraXmlEncoding.

Herve Boutemy added a comment - 02/Jan/11 4:03 AM another related fix in r1054373 : the file was saved by the plugin with platform encoding, not generated by Jira AFAIK SNAPSHOT deployed not sure at all that the jiraXmlEncoding parameter is needed, and IMHO it would better be named "forceJiraEncoding" or something like this

Dennis Lundberg added a comment - 02/Jan/11 7:49 AM Felipe, it would be great if you could test the fix that Hervé just committed. Just run the plugin as you did before, without the new encoding parameter that I added and see if that works for you. If that works, we should remove the parameter that I added.

Dennis Lundberg added a comment - 06/Jan/11 4:01 AM Hervé, do you think that I should remove the parameter that was added? We can always add it back later is it is needed.

Herve Boutemy added a comment - 22/Jan/11 4:43 PM The problem reported by Felipe is exactly what I fixed in r1054373: the calling plugin was using platform encoding of Maven JVM to save Jira result, which was not consistent with result's XML prolog. Felipe's report is the most precise we have: I consider his problem has been be fixed now, without the new configuration parameter. So I'm in favour of removing the new parameter and considering this issue fixed.

Dennis Lundberg added a comment - 23/Jan/11 4:17 AM I have reverted r1054263, as it was the wrong way to solve this issue. A new 2.4-SNAPSHOT has been deployed. Please test.