Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-6080

Unable to use alternate settings file after upgrading to Hudson 1.352

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      After upgrading a recent Hudson installation to 1.352, I'm unable to use an alternate settings.xml file. See the log:


      <===[HUDSON REMOTING CAPACITY]===>channel started
      Executing Maven: -B -f c:\hudson-slave\workspace\my-job-name\pom.xml -s ../wde/config/maven/settings.xml clean install -X

      WARNING: Alternate user settings file: ../wde/config/maven/settings.xml is invalid. Using default path.

      Please note that I want to use the file that exists at:

      c:\wde\config\maven\settings.xml

      So, I have configured the field 'Alternate settings file' to have this value:
      ../../../wde/config/maven/settings.xml

      The help text says that 'This path is relative to the workspace root.'

      I guess the workspace root in my case is:
      c:\hudson-slave\workspace\my-job-name\

      So, '../../../' would strip 3 directories, leading us to just 'c:'

      The issue also exists on version 1.351

        Attachments

          Issue Links

            Activity

            Hide
            abayer Andrew Bayer added a comment -

            See JENKINS-4693 - we fixed the logic for relative paths to alternate settings files, and you may need to update your paths to fit this.

            Show
            abayer Andrew Bayer added a comment - See JENKINS-4693 - we fixed the logic for relative paths to alternate settings files, and you may need to update your paths to fit this.
            Hide
            elifarley Elifarley added a comment -

            Using '-s C:\wde\config\maven\settings.xml' in 'Goals and options' doesn't help either.

            Show
            elifarley Elifarley added a comment - Using '-s C:\wde\config\maven\settings.xml' in 'Goals and options' doesn't help either.
            Hide
            abayer Andrew Bayer added a comment -

            I'm confused - you specified it with the ../../../ and it still showed up as just ../ in the log?

            Show
            abayer Andrew Bayer added a comment - I'm confused - you specified it with the ../../../ and it still showed up as just ../ in the log?
            Hide
            elifarley Elifarley added a comment - - edited

            Yep, that's true.

            Maybe you could call 'File.getAbsolutePath()' so that it's easier to understando where relative paths are really pointing to.

            Oh, would it be possible to accept absolute path names in the 'Alternate settings file' field too?

            Show
            elifarley Elifarley added a comment - - edited Yep, that's true. Maybe you could call 'File.getAbsolutePath()' so that it's easier to understando where relative paths are really pointing to. Oh, would it be possible to accept absolute path names in the 'Alternate settings file' field too?
            Hide
            elifarley Elifarley added a comment - - edited

            Just tested with Hudson 1.347 and it worked.

            Here's the log:

            <===[HUDSON REMOTING CAPACITY]===>
            Executing Maven: -B -f E:\hudson-slave\workspace\my-job-name\pom.xml -s E:\hudson-slave\workspace\my-job-name\../../../wde/config/maven/settings.xml clean install -e

            Show
            elifarley Elifarley added a comment - - edited Just tested with Hudson 1.347 and it worked. Here's the log: <=== [HUDSON REMOTING CAPACITY] ===> Executing Maven: -B -f E:\hudson-slave\workspace\my-job-name\pom.xml -s E:\hudson-slave\workspace\my-job-name\../../../wde/config/maven/settings.xml clean install -e
            Hide
            abayer Andrew Bayer added a comment -

            Ok, in my tests on Linux, at the very least, there is a problem in that the POM parser was still using the module root for resolving the settings file, rather than the workspace (which is what's used in the actual Maven execution). I'm committing a fix for that part of things now. But I can't reproduce the relative path resolution you're seeing - I need to find a Windows environment to test that in.

            Show
            abayer Andrew Bayer added a comment - Ok, in my tests on Linux, at the very least, there is a problem in that the POM parser was still using the module root for resolving the settings file, rather than the workspace (which is what's used in the actual Maven execution). I'm committing a fix for that part of things now. But I can't reproduce the relative path resolution you're seeing - I need to find a Windows environment to test that in.
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in hudson
            User: : abayer
            Path:
            trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java
            trunk/www/changelog.html
            http://jenkins-ci.org/commit/29304
            Log:
            JENKINS-6080 Reconciled inconsistency between module root vs workspace usage for base in resolving alternate settings path in POM parsing vs actual Maven run

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : abayer Path: trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java trunk/www/changelog.html http://jenkins-ci.org/commit/29304 Log: JENKINS-6080 Reconciled inconsistency between module root vs workspace usage for base in resolving alternate settings path in POM parsing vs actual Maven run
            Hide
            abayer Andrew Bayer added a comment -

            I'm marking this resolved for the Maven logic that was gummed up, but there is a separate problem here in terms of relative path normalization on Windows with relative paths containing "../.." vs "..\.." - the latter will work properly, but the former won't. So for now, change your relative path to use "..\.." and you'll be ok.

            Show
            abayer Andrew Bayer added a comment - I'm marking this resolved for the Maven logic that was gummed up, but there is a separate problem here in terms of relative path normalization on Windows with relative paths containing "../.." vs "..\.." - the latter will work properly, but the former won't. So for now, change your relative path to use "..\.." and you'll be ok.

              People

              Assignee:
              abayer Andrew Bayer
              Reporter:
              elifarley Elifarley
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: