[
https://issues.apache.org/jira/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15929677#comment-15929677
]
SomeDev1705 commented on SUREFIRE-951:
--------------------------------------
The original issue is still present in version 2.15. I just ran into this with
unit tests testing some UTF-8 chars on Windows.
While explicitly adding the file encoding fixes this issue, I think this
offends Maven's Convention Over Configuration approach. When I configure the
native maven property {{project.build.sourceEncoding}} I expect it to be
honored by everything Maven related i.e. the complete build. In case of some
special edge case I'm happy to configure plugins. However expecting my unit
tests to be working with the correct source encoding is no edge case at all.
For the Googlers: The fix is adding
{code:xml}
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.15</version>
<configuration>
<argLine>-Dfile.encoding=${project.build.sourceEncoding}</argLine>
</configuration>
</plugin>
{code}
(Given that you have set
{{<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>}} in your
{{properties}}.)
Also see
http://stackoverflow.com/questions/17656475/maven-source-encoding-in-utf-8-not-working
> Better handling of file.encoding system property
> ------------------------------------------------
>
> Key: SUREFIRE-951
> URL: https://issues.apache.org/jira/browse/SUREFIRE-951
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin, process forking
> Affects Versions: 2.13
> Environment: Any environment in which the file encoding is distinct
> from ${project.build.sourceEncoding}.
> Reporter: Stephan Schroevers
> Assignee: Tibor Digana
> Fix For: 2.15
>
> Attachments: file-encoding-example.tbz
>
>
> It appears that Surefire doesn't (correctly) set
> {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} prior to running the
> tests. As a result the JVM will derive {{file.encoding}} from the
> environment's file encoding. This affects the return value of
> {{java.nio.charset.Charset#defaultCharset()}}, which reads the
> {{file.encoding}} system property exactly once, and is invoked very early on.
> Concretely this means that the unit tests are unnecessarily platform
> dependent.
> Thus I have two requests:
> # Make {{-Dfile.encoding=$\{project.build.sourceEncoding\}}} the default.
> That is, the following configuration setting should be implied:
> {noformat}
> <argLine>-Dfile.encoding=${project.build.sourceEncoding}</argLine>
> {noformat}
> # Extend the method
> {{org.apache.maven.plugin.surefire.SurefireProperties#verifyLegalSystemProperties(org.apache.maven.plugin.logging.Log)}}
> such that is warns about users attempting to set the {{file.encoding}}
> property through the {{systemPropertyVariables}} configuration setting. Like
> with {{java.library.path}}, this does _not_ work.
> I have [attached|^file-encoding-example.tbz] a sample project that
> demonstrates the issue (simply run {{`mvn test`}}). Please have a look at the
> comments I added to the POM. I have tested this sample project only on Linux,
> but a colleague has confirmed that an instance of this issue can also be
> recreated on Windows.
> TIA for looking into this!
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
