[
https://issues.apache.org/jira/browse/SUREFIRE-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123328#comment-15123328
]
Michael Osipov edited comment on SUREFIRE-1220 at 1/29/16 10:43 AM:
--------------------------------------------------------------------
Just tested this on:
{noformat}
D:\surefire-1220>mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: D:\Entwicklung\Programme\apache-maven-3.3.9\bin\..
Java version: 1.8.0_72, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_72\jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "windows 10", version: "10.0", arch: "amd64"
{noformat}
After an analysis, the problem is not Maven or Surefire. I see in my hex editor
that Java happily writes {{U+2025}}( ‥ ) in UTF-8 as {{0xE2 0x80 0xA5}}.
Windows 10 command prompt provides two true type fonts. If you open up the
character map for these fonts in LibreOffice Writer or Windows Character Map,
you'll see that right after {{U+2025}} comes {{U+2026}} thus the caracter is
not included. Compare with Linux LIbertine or DejaVu Sans, both fonts have this
character. I'd recommend to file an issue with to Guava to change the
{{toString}} representation either to a mathematical range inclusive range
expression: {{[10,30]}} or using a proper [en
dash|https://en.wikipedia.org/wiki/Dash#Ranges_of_values] for it: {{10–30}}.
See my attached screenshot.
was (Author: michael-o):
Just tested this on:
{noformat}
D:\surefire-1220>mvn --version
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
2015-11-10T17:41:47+01:00)
Maven home: D:\Entwicklung\Programme\apache-maven-3.3.9\bin\..
Java version: 1.8.0_72, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.8.0_72\jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "windows 10", version: "10.0", arch: "amd64"
{noformat}
After an analysis, the problem is not Maven or Surefire. I see in my hex editor
that Java happily writes {{U+2025}}( ‥ ) in UTF-8 as {{0xE2 0x80 0xA5}}.
Windows 10 command prompt provides two true type fonts. If you open up the
character map for these fonts in LibreOffice Writer, you'll see that right
after {{U+2025}} comes {{U+2026}} thus the caracter is not included. Compare
with Linux LIbertine or DejaVu Sans, both fonts have this character. I'd
recommend to file an issue with to Guava to change the {{toString}}
representation either to a mathematical range inclusive range expression:
{{[10,30]}} or using a proper [en
dash|https://en.wikipedia.org/wiki/Dash#Ranges_of_values] for it: {{10–30}}.
See my attached screenshot.
> Surefire never outputs UTF-8 under Windows
> ------------------------------------------
>
> Key: SUREFIRE-1220
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1220
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
> Affects Versions: 2.19.1
> Environment: Windows 10, 64-bit
> DejaVu Sans font
> Reporter: Gili
> Labels: close-pending
> Attachments: 2016-01-29_113906.png, surefire-1220.zip
>
>
> I'm having problems getting Surefire to output UTF-8 fonts under Windows.
> When I run a unit test that outputs a Guava Range ("10‥20") the TWO DOT
> LEADER unicode character always gets rendered as a question mark.
> If I run the exact same code outside of Surefire (using a main() entry point)
> the UTF-8 character renders just fine. The repro steps are quite simple:
> # Create a Maven project.
> # Run {code}System.out.println(Range.closed(10, 30));{code} in a Java class
> with a main() entry point, and from a JUnit test.
> # The main() entry point will output UTF-8 just fine. The JUnit test will
> output a question mark in place of the unicode.
> Here is my pom.xml file:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.mycompany</groupId>
> <artifactId>mavenproject1</artifactId>
> <version>1.0-SNAPSHOT</version>
> <packaging>jar</packaging>
> <build>
> <plugins>
> <plugin>
> <groupId>org.apache.maven.plugins</groupId>
> <artifactId>maven-surefire-plugin</artifactId>
> <version>2.19.1</version>
> <configuration>
> <argLine>-Dfile.encoding=UTF-8</argLine>
> </configuration>
> </plugin>
> <plugin>
> <groupId>org.codehaus.mojo</groupId>
> <artifactId>exec-maven-plugin</artifactId>
> <version>1.4.0</version>
> <executions>
> <execution>
> <goals>
> <goal>java</goal>
> </goals>
> </execution>
> </executions>
> <configuration>
> <mainClass>foo.Main</mainClass>
> </configuration>
> </plugin>
> </plugins>
> </build>
> <dependencies>
> <dependency>
> <groupId>com.google.guava</groupId>
> <artifactId>guava</artifactId>
> <version>19.0</version>
> </dependency>
> <dependency>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>4.12</version>
> <scope>test</scope>
> </dependency>
> </dependencies>
> <properties>
> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
> <maven.compiler.source>1.8</maven.compiler.source>
> <maven.compiler.target>1.8</maven.compiler.target>
> </properties>
> </project>
> {code}
> I tried the same thing using TestNG tests and noticed that although output to
> console was still wrong, the outputted testng-results.xml file contained the
> correct character.
> Can you reproduce this on your end?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
