Skip to content
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

XMLTest.testIndentComplicatedJsonObjectWithArrayAndWithConfig fails on Windows #781

Closed
mureinik opened this issue Oct 5, 2023 · 3 comments · Fixed by #782
Closed

XMLTest.testIndentComplicatedJsonObjectWithArrayAndWithConfig fails on Windows #781

mureinik opened this issue Oct 5, 2023 · 3 comments · Fixed by #782

Comments

@mureinik
Copy link
Contributor

mureinik commented Oct 5, 2023

When running the test suite on Windows, XMLTest.testIndentComplicatedJsonObjectWithArrayAndWithConfig fails due to differences in the newline character being used in the expected and actual XMLs being compared - differences that are no functionally interesting.

The test properly canonized the newline character in the actual string produced by calling XML.toString, but fails to do so for the expected string that was read from a file. Since this file was not produced on a Windows machine, it won't contain the linebreaks expected when the test is run on Windows.

mureinik added a commit to mureinik/JSON-java that referenced this issue Oct 5, 2023
XMLTest.testIndentComplicatedJsonObjectWithArrayAndWithConfig fails
when run on Windows due to mismatching linebreaks (that aren't
important for the test's functionality) between the actual and
expected strings.

For the actual strings, linebreaks are canonized to the platform's
native linebreak using `replaceAll("\\n|\\r\\n",
System.getProperty("line.separator")`. However, the expected result is
read from a file, and is left with the linebreaks that were originally
used to create it.

The solution is to perform the same canonization on both strings.

Closes stleary#781
@stleary
Copy link
Owner

stleary commented Oct 5, 2023

@mureinik Isn't this fixed in #782?

@mureinik
Copy link
Contributor Author

mureinik commented Oct 5, 2023

@stleary yes, it is - I mentioned it on the PR, and let GitHub's automatic quoting mention it back here.

I didn't want to submit a PR without context, so I preferred opening a bug and then submitting a fix for it.

@stleary
Copy link
Owner

stleary commented Oct 6, 2023

Fixed in #782

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants