release:prepare does not pass argument "--settings" with current settings.xml to inner maven

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.0-beta-9, 2.0
  • Fix Version/s: 2.2.2
  • Component/s: prepare

Description

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 .....

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MRELEASE-521 release:perform does not take the settings specified by the -s option

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-5224 REGRESSION: Injected Settings in a Mojo are missing the profiles from settings.xml

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stephen Connolly added a comment - - edited

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.
Show
Stephen Connolly added a comment - - edited 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.
Hide
Permalink
Christoph Kutzinski added a comment -

As mentioned in MRELEASE-521 the perform goal is affected by the same problem.

Show
Christoph Kutzinski added a comment - As mentioned in MRELEASE-521 the perform goal is affected by the same problem.
Hide
Permalink
Stevo Slavic added a comment -

Isn't arguments meant for passing arguments to inner Maven executions?

Show
Stevo Slavic added a comment - Isn't arguments meant for passing arguments to inner Maven executions?
Hide
Permalink
Derek Lewis added a comment -

Using -Darguments is the workaround we have had to use. However, we set a large number of profiles (and a few properties) for our release build, which ends up meaning we have to list them all twice, once to the outer execution of Maven, and once in -Darguments. Most of the profiles we enable are profiles that include submodules into the reactor, so if we don't set them twice like that, the inner Maven execution doesn't actually build the same modules.
I realize this isn't the same as passing the the settings file to the inner execution, but it seems to me to be related.

Show
Derek Lewis added a comment - Using -Darguments is the workaround we have had to use. However, we set a large number of profiles (and a few properties) for our release build, which ends up meaning we have to list them all twice, once to the outer execution of Maven, and once in -Darguments. Most of the profiles we enable are profiles that include submodules into the reactor, so if we don't set them twice like that, the inner Maven execution doesn't actually build the same modules. I realize this isn't the same as passing the the settings file to the inner execution, but it seems to me to be related.
Hide
Permalink
Stephen Connolly added a comment -

r1213763

Show
Stephen Connolly added a comment - r1213763
Hide
Permalink
Stephen Connolly added a comment -

r1213780

Show
Stephen Connolly added a comment - r1213780
Hide
Permalink
Joseph Walton added a comment -

This change seems to publish the passwords from a private settings.xml into a world-readable file in /tmp during a build.

Show
Joseph Walton added a comment - This change seems to publish the passwords from a private settings.xml into a world-readable file in /tmp during a build.
Hide
Permalink
Joseph Walton added a comment -

Note that this change will not work in Maven 3.0.3 due to MNG-5224.

Show
Joseph Walton added a comment - Note that this change will not work in Maven 3.0.3 due to MNG-5224.
Hide
Permalink
Anca Luca added a comment -

Added the link to issue MNG-5224 to mark the relation between the two.

Show
Anca Luca added a comment - Added the link to issue MNG-5224 to mark the relation between the two.

People

  • Assignee:
    Stephen Connolly
    Reporter:
    Petr Kozelka
Vote (4)
Watch (5)

Dates

  • Created:
    Updated:
    Resolved: