-
Notifications
You must be signed in to change notification settings - Fork 127
Numbers in XML report are formatted based on Locale #126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I wonder if the XML standard specifies that numbers should be formatted in the UK / USA style. It's easily changed. |
I haven't checked any standards so far (and I'm in doubt that XML is that specific, considering that values usually are just strings from an xml point of view) but it seems logical to me from a portability point of view. For me this might as well be fixed in the jenkins plugin (by parsing the numbers in a locale-dependent way) since everything runs on the same system, but this might not work in every case, that's why i filed the report here. |
According to the datatypes definition of the XML Schema, the numbers have to be formatted with a dot as a delimiter: http://www.w3.org/TR/xmlschema-2/#decimal-lexical-representation |
Release 1.2.0 contains fixes for that problem, can you please check if it works correctly for you? |
I just updated our projects to sbt-scoverage 1.5.0, which depends on scalac-scoverage-plugin 1.3.0 and the problem is gone. thank you very much :) |
We are currently setting up scoverage on a handful of our play framework / activator based apps, and we noticed that the coverage display in the jenkins plugin did not work as expected (it kept showing 0% coverage, even though values in the html report were higher).
upon further inspection, we found that the jenkins plugin expects the values "statement-rate" and "branch-rate" in the coverage report XML to be parseable by Double.parseDouble(), e.g. "12.34", while the reports generated by our build contained numbers that are formatted according to our system locale setting ("de_DE.UTF-8"), e.g. "12,34" (notice the comma).
This might be debatable, but in my opinion an XML file should be portable between systems of different locales, and as such the locale should not have an influence on its contents. Checking the code this does not appear to be intentional to me either.
The text was updated successfully, but these errors were encountered: