You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Stephan Schroevers (JIRA)" <ji...@codehaus.org> on 2013/01/15 12:03:13 UTC
[jira] (SUREFIRE-951) Better handling of file.encoding system
property
Stephan Schroevers created SUREFIRE-951:
-------------------------------------------
Summary: Better handling of file.encoding system property
Key: SUREFIRE-951
URL: https://jira.codehaus.org/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
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-951) Better handling of file.encoding system
property
Posted by "Stephan Schroevers (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317337#comment-317337 ]
Stephan Schroevers commented on SUREFIRE-951:
---------------------------------------------
Thinking about it some more, I guess any unit test that relies on a _specific_ default encoding is faulty, so the case can be made that point (1) above _should not be_ necessary. Would like to hear other people's thoughts on that.
> Better handling of file.encoding system property
> ------------------------------------------------
>
> Key: SUREFIRE-951
> URL: https://jira.codehaus.org/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
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (SUREFIRE-951) Better handling of file.encoding system
property
Posted by "Stephan Schroevers (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319824#comment-319824 ]
Stephan Schroevers commented on SUREFIRE-951:
---------------------------------------------
Another property that only takes effect when set using {{<argLine>}} (i.e., not when using {{<systemPropertyVariables>}}) is [{{jdk.map.althashing.threshold}}|http://docs.oracle.com/javase/7/docs/technotes/guides/collections/changes7.html]. (Perhaps I should create a separate ticket for that?)
> Better handling of file.encoding system property
> ------------------------------------------------
>
> Key: SUREFIRE-951
> URL: https://jira.codehaus.org/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
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira