[jira] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://jira.codehaus.org/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=340235#comment-340235
]
Karel Piwko commented on MNG-5199:
--
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
Return back org.apache.maven.user-settings and
org.apache.maven.global-settings properties
--
Key: MNG-5199
URL: https://jira.codehaus.org/browse/MNG-5199
Project: Maven 2 3
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.1.6#6162)
[jira] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://jira.codehaus.org/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=339932#comment-339932
]
Jason van Zyl commented on MNG-5199:
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?
Return back org.apache.maven.user-settings and
org.apache.maven.global-settings properties
--
Key: MNG-5199
URL: https://jira.codehaus.org/browse/MNG-5199
Project: Maven 2 3
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5199) Return back org.apache.maven.user-settings and org.apache.maven.global-settings properties
[
https://jira.codehaus.org/browse/MNG-5199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=322131#comment-322131
]
Jörg Hohwiller commented on MNG-5199:
-
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.
Return back org.apache.maven.user-settings and
org.apache.maven.global-settings properties
--
Key: MNG-5199
URL: https://jira.codehaus.org/browse/MNG-5199
Project: Maven 2 3
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
