[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)