[JIRA] (JENKINS-53237) Maven Surefire Report XSD requires a fix

[nfalc...@hotmail.com (JIRA)]

Title: Message Title

Nikolas Falco commented on JENKINS-53237   Re: Maven Surefire Report XSD requires a fix Not sure why you validate XML but anyway. I validate report in input to reduce possible unexpected parse/transformer (XSLT for not junit report) errors. This make easier resolve bugs. Since JUnit it's just a library and does not produce a report since 2.0 of xunit-plugin, supported JUnit report are those produced by the ant task and maven surefire. The XSD is compatible for both. Parsing the XML and displaying the statistics is what has to be done by the plugins. Yes but testsuite attributes meaningful depends from version. What I wanted to say with "At this point why do not add an attribute to mark the differences between flaky failures and failure also in the XML" is that when rerun feature was introduced if had been added additional attribute for flaky failures (maybe also an attribute for runs) the XML would be full backward compatible at all because the attributes had the same meaningful of before. Now we have the root testsuite element that declare 10 tests and 2 failures when in real you have only 7 test method (but 10 runs...) and no failures. <testsuite name="...FooTest" time="0" tests="7" errors="0" skipped="0" failures="0" runs="10" flakyfailures="2"> About the XSD version for what I can see for other software I consider a best practice publish XSD for each version and the XML declare the path to the specific XSD version <testsuite ... xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report" ... /> (to be compatible with actual) <testsuite ... xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-2.2.xsd" ... /> <testsuite ... xsi:noNamespaceSchemaLocation="https://maven.apache.org/surefire/maven-surefire-plugin/xsd/surefire-test-report-3.0.xsd" ... /> If the change present in 3.0 version, we would have to wait quite long time and there would be a risk that the rerun feature as well as flaky failures are heavily used. From the point of view of end user if I get an error updating from 2.x to 2.22.1 I have good reason to open a bug. In 3.x thanks to semantic versioning you can answer "we have changed the format". These kind of changes from 2.22.0 to 2.22.1 is much less reasonable, it looks more like a bug. Add Comment   This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.