[jira] [Commented] (SUREFIRE-951) Better handling of file.encoding system property
[
https://issues.apache.org/jira/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554741#comment-15554741
]
Francois MAROT commented on SUREFIRE-951:
-
Just want to share my experience. After switching to Windows from Linux, I
stumbled onto a failed unit test:
final String tmp = new String("IBAÑEZ/9");
String toTest = new String(tmp.getBytes(), Charsets.UTF_8);
Assert.assertTrue(tmp.equals(toTest));
It was OK on Linux but KO on windows because SUREFIRE does not default to what
I thought was a global Maven parameter "project.build.sourceEncoding". In my
opinion, the principle of least astonishment would favor defaulting to this
parameter by default.
My 2 cents
> 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: Kristian Rosenvold
> 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}
> -Dfile.encoding=${project.build.sourceEncoding}
> {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.4#6332)
[jira] [Commented] (SUREFIRE-951) Better handling of file.encoding system property
[
https://issues.apache.org/jira/browse/SUREFIRE-951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15565114#comment-15565114
]
Francois MAROT commented on SUREFIRE-951:
-
[~tibor17] Can you point me to the repository containing the SNAPSHOTS version
please ? Or better directly give me the pom content ;)
> 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}
> -Dfile.encoding=${project.build.sourceEncoding}
> {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.4#6332)
[jira] [Created] (MNG-6336) Aggregator Mojo should be executed only once even when part of the lifecycle
Francois MAROT created MNG-6336: --- Summary: Aggregator Mojo should be executed only once even when part of the lifecycle Key: MNG-6336 URL: https://issues.apache.org/jira/browse/MNG-6336 Project: Maven Issue Type: Improvement Components: core Affects Versions: 3.5.2 Reporter: Francois MAROT Priority: Minor Currently aggregator Mojo (annotated with @Mojo(aggregator=true, ...) ) are used to define Mojo whose goal whould be called directly, not bound to a lifecycle phase. This is the case for release:prepare / release:perform for exemple. I would be good if such aggregator Mojo ware also executed only once when part of a lifecycle. Currently we have to specify false in the pom. It would comply to the principle of least surprise because it seems every doc I found just say something "like these Mojo will be executed only once", and do not specify "in the case of direct invocation". I first reported this behavior on the mailing list: http://maven.40175.n5.nabble.com/Make-custom-plugin-executed-only-once-in-multimodule-inherited-false-aggregator-td5921630.html This JIRA may be related to improvement in the lifecycle ( MNG-5665 ) as suggested by [~rfscholte] -- This message was sent by Atlassian JIRA (v6.4.14#64029)
