ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 49418] Add support for non-ASCII encoding to <junitreport> task
Date Fri, 11 Jun 2010 14:06:51 GMT

--- Comment #6 from Jesse Glick <> 2010-06-11 10:06:48 EDT ---
(In reply to comment #5)
> The problem was actually in stderr outputs shown in the summary

Ah, yes - because it is written to a text file which cannot signify its

> I don't think it would be sufficient to
> hardcode UTF-8 instead of US-ASCII, because some Java environments have default
> encodings that are not compatible to UTF-8.  For example, Sun's JDK for
> Japanese Windows has MS932 as its default encoding.

Doesn't really matter what the JDK's default encoding is; you can still write
output in any encoding you like.

> I couldn't manage to make such a patch, but using the default encoding of the
> system as that of the stylesheets for junitreport might be more reasonable.

It's easy to do and I will attach a patch.

The question is which patch is better. The encoding used for the HTML pages
does not matter much (since output will be written with character references if
necessary); it is a bit nicer to use UTF-8 but not essential. Regarding the
plain text output, there are arguments in either direction:

1. Using platform default encoding may be convenient if the web browser used to
view the result is on the same machine as the one which ran <junitreport>, or
which otherwise happens to have the same default encoding, and the web browser
is set to use the platform default encoding by default for pages specifying no
encoding (and is unable to sniff the encoding).

2. Using UTF-8 ensures that no characters will ever be dropped as unencodable,
i.e. output will never be lossy. At worst you may need to take a special action
to display the page in UTF-8.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

View raw message