[jira] [Comment Edited] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439272#comment-15439272
]
Louis Lecaroz edited comment on MNG-5199 at 8/26/16 3:35 PM:
-
Yes sure Jason and Karel.
Fully agreed with you !
But because Maven is an opened environment allowing lot of third party
providers to propose their own plugins... Lot of them are isolating by spawning
new mvn child instances (specially for unit tests for example). & lot of them
cannot be configured for mentioning the settings.xml to be used. In
consequence, the global maven settings.xml is taken in account & if you need a
specific default setting, you will have to modify this maven\conf\settings.xml.
& this can be a problem in ci/builds servers because sometimes, some builds
need their own settings. So global settings need also to be isolated to be
modified without impacting other builds.
& one of the clean ways for doing this properly is to specify the global
settings in the maven_opts which can be set for each of your builds.
MAVEN_OPTS & org.apache.maven.* properties appears to be the most universal way
as the MAVEN_OPTS environment variable is generally also propagated
automatically & some third party maven plugins can spawn child mvn instances
thru intermediate programs or batch files which cannot be controled thru an
API, or whatever you want.
I hope that I was able to clearly communicate the problem. being able to set
such settings (settings, toolchain, ...) outside from the maven\conf dir will
be great & help installations in complex environments to be more robust.
Really thx in advance
Best regards
Louis
was (Author: llecaroz):
Yes sure Jason.
Fully agreed with you !
But because Maven is an opened environment allowing lot of third party
providers to propose their own plugins... Lot of them are isolating by spawning
new mvn child instances (specially for unit tests for example). & lot of them
cannot be configured for mentioning the settings.xml to be used. In
consequence, the global maven settings.xml is taken in account & if you need a
specific default setting, you will have to modify this maven\conf\settings.xml.
& this can be a problem in ci/builds servers because sometimes, some builds
need their own settings. So global settings need also to be isolated to be
modified without impacting other builds.
& one of the clean ways for doing this properly is to specify the global
settings in the maven_opts which can be set for each of your builds.
MAVEN_OPTS & org.apache.maven.* properties appears to be the most universal way
as the MAVEN_OPTS environment variable is generally also propagated
automatically & some third party maven plugins can spawn child mvn instances
thru intermediate programs or batch files which cannot be controled thru an
API, or whatever you want.
I hope that I was able to clearly communicate the problem. being able to set
such settings (settings, toolchain, ...) outside from the maven\conf dir will
be great & help installations in complex environments to be more robust.
Really thx in advance
Best regards
Louis
> 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)
[jira] [Commented] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439272#comment-15439272
]
Louis Lecaroz commented on MNG-5199:
Yes sure Jason.
Fully agreed with you !
But because Maven is an opened environment allowing lot of third party
providers to propose their own plugins... Lot of them are isolating by spawning
new mvn child instances (specially for unit tests for example). & lot of them
cannot be configured for mentioning the settings.xml to be used. In
consequence, the global maven settings.xml is taken in account & if you need a
specific default setting, you will have to modify this maven\conf\settings.xml.
& this can be a problem in ci/builds servers because sometimes, some builds
need their own settings. So global settings need also to be isolated to be
modified without impacting other builds.
& one of the clean ways for doing this properly is to specify the global
settings in the maven_opts which can be set for each of your builds.
MAVEN_OPTS & org.apache.maven.* properties appears to be the most universal way
as the MAVEN_OPTS environment variable is generally also propagated
automatically & some third party maven plugins can spawn child mvn instances
thru intermediate programs or batch files which cannot be controled thru an
API, or whatever you want.
I hope that I was able to clearly communicate the problem. being able to set
such settings (settings, toolchain, ...) outside from the maven\conf dir will
be great & help installations in complex environments to be more robust.
Really thx in advance
Best regards
Louis
> 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)
[jira] [Comment Edited] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://issues.apache.org/jira/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15439186#comment-15439186
]
Louis Lecaroz commented on MNG-5199:
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)
[jira] Created: (SCM-496) org.apache.maven.scm.NoSuchCommandScmException: No such command 'list' when the Perforce SCM Provider is used by the SCM Wagon in maven deploy
org.apache.maven.scm.NoSuchCommandScmException: No such command 'list' when the Perforce SCM Provider is used by the SCM Wagon in maven deploy Key: SCM-496 URL: http://jira.codehaus.org/browse/SCM-496 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-perforce Environment: Maven 2.2.1, jdk 1.6 SR16, Win32 Reporter: Louis Lecaroz Priority: Critical Attachments: pom.xml After having taken a look in the svn in trunk, the AbstractScmProvider its implementations except Perforce implement the AbstractScmProvider.list() method. As this method is called by the ScmWagon, because it is not implemented in the PerforceScmProvider, it generates this exception (generated by the AbstractScmProvider.list() code ) : Uploading: scm:perforce:lleca...@pperforce.server.com:1971://experiments/llecaroz/Maven/Repository/demo/foo/app/tp.sun.java-test-1/1.2-SNAPSHOT/tp.sun.java-test-1-1.2-20090903.105728-1.jar [INFO] No password found, proceeding without it. [DEBUG] No such command 'list'. org.apache.maven.scm.NoSuchCommandScmException: No such command 'list'. at org.apache.maven.scm.provider.AbstractScmProvider.list(AbstractScmProvider.java:595) at org.apache.maven.scm.provider.AbstractScmProvider.list(AbstractScmProvider.java:579) at org.apache.maven.wagon.providers.scm.ScmWagon.checkOut(ScmWagon.java:371) at org.apache.maven.wagon.providers.scm.ScmWagon.putInternal(ScmWagon.java:285) at org.apache.maven.wagon.providers.scm.ScmWagon.put(ScmWagon.java:254) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:173) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) So I was unable to use the Perforce SCM Provider as SCM Wagn as you will see in this simplified attached/POM(testcase) to reproduce the issue. Don't forget to replace the url username by a working one. To run it : -detach this pom -modify the url to a valid perforce server -launch maven deploy Tried with svn just by switching the extension from perforce into svn modifying the url : no problem... as svn provider implements the list() method. So the list() method needs to be implemented in the PerforceScmProvider as solution. At this time from my understanding, no project can use perforce as repository. Thx in advance Louis -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
