[MNG-5199] Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties

[jira-importer]

Karel Piwko opened MNG-5199 and commented

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:

mvn -s setting.xml test 

Surefire has no way 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:

mvn -Dorg.apache.maven.user-settings=settings.xml test

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.

---

Affects: 3.0.3

9 votes, 10 watchers

[jira-importer]

Jörg Hohwiller commented

Yes. Please add this feature.
See also:
http://maven.40175.n5.nabble.com/Maven-3-support-for-org-apache-maven-user-settings-td3261146.html
https://issues.jenkins-ci.org/browse/JENKINS-8704

There are use-cases where this feature makes sense and is very helpful.
I am working with various projects on the same machine. Each project has its own settings.
I added an option that if I open the context menu of a folder, I can open a shell.
Then it automatically finds the project root and sets environment variables accordingly (JAVA_HOME, MAVEN_HOME, MAVEN_OPTS, PATH, etc.).
I want to be able to just call "mvn ..." and have everything working for the right project.
The only workaround I found so far is to add something like "-Duser.home=project/conf/" to MAVEN_OPTS.
However, this is a hack and has undesired side effects.

Are there any reasons why this ticket is not implemented except for time and effort?
I might be willing to try creating a patch. But only if the chances are really high to get this into the mainline.

[jira-importer]

Jason van Zyl commented

So this is primarily a deficiency in the way options are passed on spawned execution environments. So if the -s parameter was passed on properly this would not be an issue yes?

[jira-importer]

Karel Piwko commented

Yes, I believe this is a deficiency in spawned execution environments. There are more information about Maven execution that could be propagated to outside world, such as http://jira.codehaus.org/browse/SUREFIRE-790

[jira-importer]

Roy Teeuwen commented

Any update on this issue? This is for us also an issue in CI environments.

[jira-importer]

Louis Lecaroz commented

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/

[jira-importer]

Louis Lecaroz commented

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