[jira] [Comment Edited] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties

["Louis Lecaroz (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15439186#comment-15439186 ] 

Louis Lecaroz edited comment on MNG-5199 at 8/26/16 2:59 PM:
-------------------------------------------------------------

In CI environments, also having projects using Maven third parties plugins or surefire, not taking care of a project settings.xml & in consequence the global settings.xml is taken in account in place. But because some settings depends on the CI build & multiple CI builds are running on the same slave. the global settings.xml must be part of the build directory instead of the maven installation dir. So the org.apache.maven.global-settings will be useful for isolating global settings.xml read by third parties maven plugins in each corresponding build. 

The goal of such variables (org.apache.maven.user-settings and org.apache.maven.global-settings properties)  is to have only fixed file (like binaries for ex...) in M2_HOME (or MAVEN_HOME) & all configuration files like toolchain, settings.xml set thru the MAVEN_OPTS variable to fully isolate each maven contexts in each build

Other reference link: http://blog.vanpeerdevelopment.be/2013/12/26/maven3-and-org.apache.maven.user-settings/


was (Author: llecaroz):
In CI environments, also having projects using Maven third parties plugins or surefire, not taking care of a project settings.xml & in consequence the global settings.xml is taken in account in place. But because some settings depends on the CI build & multiple CI builds are running on the same slave. the global settings.xml must be part of the build directory instead of the maven installation dir. So the org.apache.maven.global-settings will be useful for isolating global settings.xml read by third parties maven plugins in each corresponding build. 

The goal of such variables (org.apache.maven.user-settings and org.apache.maven.global-settings properties)  is to have only fixed file (like binaries for ex...) in M2_HOME (or MAVEN_HOME) & all configuration files like toolchain, settings.xml set thru the MAVEN_OPTS variable to fully isolate each maven contexts in each build

> Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
> ------------------------------------------------------------------------------------------
>
>                 Key: MNG-5199
>                 URL: https://issues.apache.org/jira/browse/MNG-5199
>             Project: Maven
>          Issue Type: New Feature
>          Components: Settings
>    Affects Versions: 3.0.3
>            Reporter: Karel Piwko
>
> According to discussion at http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html, I'm sure there is a valid use case for the property:
> Imagine following:
> {code}
> mvn -s setting.xml test 
> {code}
> Surefire has no way how to pass the path of the settings.xml in the spawned process. If the test in spawned process want to for example access remote repository defined in settings.xml, user has to specify settings.xml path in the test itself.
> However, for the following:
> {code}
> mvn -Dorg.apache.maven.user-settings=settings.xml test
> {code}
> This system property can be passed to surefire configuration and propagated to the Surefire spawned process later on.
> Having a system property removes duplication of the environment settings.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)