Maven Release Plugin
  1. Maven Release Plugin
  2. MRELEASE-577

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
    • Number of attachments :
      0

      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

          Activity

          Hide
          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
          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
          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
          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
          Stephen Connolly added a comment -

          r1213763

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

          r1213780

          Show
          Stephen Connolly added a comment - r1213780
          Hide
          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
          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
          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
            • Votes:
              4 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: