You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Stephen Connolly (JIRA)" <ji...@codehaus.org> on 2011/07/01 13:23:42 UTC
[jira] Issue Comment Edited: (MRELEASE-577) release:prepare does
not pass argument "--settings" with current settings.xml to inner maven
[ https://jira.codehaus.org/browse/MRELEASE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=272027#comment-272027 ]
Stephen Connolly edited comment on MRELEASE-577 at 7/1/11 6:21 AM:
-------------------------------------------------------------------
It is not possible to get the location of the settings.xml from within a Maven plugin.
Embedding maven may result in there actually being no settings.xml at all, with all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something like:
Add a boolean parameter to prepare and stage goals that enables the following:
* Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
[]
When forking maven, if there is a release.settings.xml file have the fork use that settings.xml
The patch will need tests.
w.r.t. password encryption, the ${settings} stores the password encrypted in memory so serialization will still write out the encrypted password.
w.r.t. other gotcha's... you will need to ensure that release.settings.xml is ignored in the check for modified files
was (Author: stephenconnolly):
It is not possible to get the location of the settings.xml from within a Maven plugin.
Embedding maven may result in there actually being no settings.xml at all, with all the required information being provided by the embedder.
If somebody wants to take a stab at a patch for this, you would do something like:
Add a boolean parameter to prepare and stage goals that enables the following:
* Use MavenSettingsXpp3Writer to write the ${settings} to release.settings.xml
When forking maven, if there is a release.settings.xml file have the fork use that settings.xml
The patch will need tests.
w.r.t. password encryption, the ${settings} stores the password encrypted in memory so serialization will still write out the encrypted password.
w.r.t. other gotcha's... you will need to ensure that release.settings.xml is ignored in the check for modified files
> release:prepare does not pass argument "--settings" with current settings.xml to inner maven
> --------------------------------------------------------------------------------------------
>
> Key: MRELEASE-577
> URL: https://jira.codehaus.org/browse/MRELEASE-577
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
> Affects Versions: 2.0-beta-9, 2.0
> Reporter: Petr Kozelka
> Priority: Critical
>
> The impact is that release:prepare tries to use $HOME/.m2/settings.xml instead of the one supplied by --settings cmdline option, which leads to unexpected behavior
> Of course if it does not exist, the inhouse repository is avoided and release often fails due to a ResourceDoesNotExistException when an inhouse artifact is requested by the pom.
> To reproduce this problem, just rename your ~/.m2/settings.xml to ~/.m2/s.xml and run this:
> mvn --settings=$HOME/.m2/s.xml release:prepare .....
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira