[SUREFIRE-951] Better handling of file.encoding system property

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 2.13
• Fix Version/s: 2.15
• Component/s: Maven Surefire Plugin, process forking
• Environment: Any environment in which the file encoding is distinct from ${project.build.sourceEncoding}.
• Assignee: Tibor Digana
• Reporter: Stephan Schroevers
• Created: 15/Jan/13 05:01
• Updated: 5 days ago 00:16
• Resolved: 03/May/13 16:03

Description

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:

1. Make -Dfile.encoding=${project.build.sourceEncoding} the default. That is, the following configuration setting should be implied:

   <argLine>-Dfile.encoding=${project.build.sourceEncoding}</argLine>
   

2. 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 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!

Issue Links

• relates to: SUREFIRE-709 Can't set system properties by <systemPropertyVariables> or <argLine> on Maven 3.0.2