maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Gudian (JIRA)" <>
Subject [jira] [Commented] (SUREFIRE-1137) Problem with Umlauts in stdout
Date Mon, 01 Feb 2016 19:49:39 GMT


Andreas Gudian commented on SUREFIRE-1137:

[~michael-o], well, that's too long ago for me to remember. What I do remember is that I kept
trying out different approaches and it took more than one iteration to get it to the point
where it was then.

OK, I checked the commit as well. I think one problem that I had was that specifying {{-Dfile.encoding}}
didn't always have the desired effect. That's also kind of what the docs say, which is: don't
trust that thing - it's more of an internal piece of information that may be used by some
of the JRE classes, but it is never guaranteed that it is actually obeyed. Other information
from the installation, the system or the environment variables can come into play as well.

So why using {{ISO-8859-1}}? It's pretty arbitrary, but it is one of the canonical charsets
that contain ASCII in unchanged form. It's just a fixture to transport the ASCII-fied information
between the forks. Byte arrays are to be transferred as they are (but printable), CharSequences
are transported using their unicode codepoints in ASCII. All of them are reconstructed on
the other side hopefully to their original state. For some output variants, Strings encoded
as byte-arrays need to be re-coded to fit a target encoding (e.g. the XML files need to be
UTF-8)... So far for the idea...

But you're right with the StreamPumpers... The intention was to pass the charset in {{CommandLineUtils.executeCommandLineAsCallable}}
to the {{StreamPumper}} instances. If the host process uses a charset that doesn't start with
the ASCII table, we're in trouble. No idea if that wouldn't break even more things than just
some glitches in the output, though... 

> Problem with Umlauts in stdout
> ------------------------------
>                 Key: SUREFIRE-1137
>                 URL:
>             Project: Maven Surefire
>          Issue Type: Bug
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.18
>         Environment: Linux
>            Reporter: J├╝rgen Zeller
>            Assignee: Andreas Gudian
>             Fix For: 2.19
>         Attachments: TEST-eu.jzeller.AppTest.xml,,
> When using Cp1252 as file encoding, the generated Surefire stdout report contains invalid
characters when run on Linux. When running the same test on Windows, everything is fine.
> A simular Problem was reported in SUREFIRE-998

This message was sent by Atlassian JIRA

View raw message