• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • maven-plugin
    • None
    • Platform: PC, OS: Linux

      The settings.xml for maven is part of the workspace and checked out of SVN
      together with the source source-code just before maven is executed. To configure
      maven the "alternate settings file" option is used, but the final path is not
      correct.

      The setup is two SVN urls that must be checked out:
      http://.../sccm-test
      http://.../sccm/sccm-conf

      The second project contains the settings.xml.

      Some examples of what we see:

      Alternate settings file: sccm-conf/settings.xml ->
      Resulting Maven '-s' option:
      /sccm/var/db/hudson/FFFJ/jobs/Development
      build/workspace/sccm-test/sccm-conf/settings.xml

      Alternate settings file: ../sccm-conf/settings.xml
      Resulting Maven '-s' option:
      /sccm/var/db/hudson/FFFJ/jobs/Development build/workspace/../sccm-conf/settings.xml
      -> Simplified: /sccm/var/db/hudson/FFFJ/jobs/Development
      build/sccm-conf/settings.xml

      Alternate settings file: ../workspace/sccm-conf/settings.xml
      Resulting Maven '-s' option:
      /sccm/var/db/hudson/FFFJ/jobs/Development
      build/workspace/sccm-test/../workspace/sccm-conf/settings.xml
      -> Simplified: /sccm/var/db/hudson/FFFJ/jobs/Development
      build/workspace/workspace/sccm-conf/settings.xml

      Alternate settings file: ../../workspace/sccm-conf/settings.xml
      Resulting Maven '-s' option:
      /sccm/var/db/hudson/FFFJ/jobs/Development
      build/workspace/../../workspace/sccm-conf/settings.xml
      -> Simplified: /sccm/var/db/hudson/FFFJ/jobs/workspace/sccm-conf/settings.xml

      It seems that entering .. is interpreted by the Java code and then also by the
      platform?

          [JENKINS-4693] Alternate settings file not found

          Stevo Slavić added a comment -

          I'm experiencing similar issue related to alternate settings file feature in
          Hudson ver. 1.329 and after upgrade it has been reproduced in Hudson ver. 1.332
          too. Help for "Alternate settings file" field suggests that path should be
          relative to workspace root; regardless if build's "Local module directory" is
          empty or not, when build starts Hudson seems to check for existence of
          configured settings.xml file but it does so using wrong file path: to the job
          workspace Hudson wrongfully appends "Local module directory" (if empty then it
          appends last path component of URL), and then appends path configured as
          "Alternate settings file" which already contains "Local module directory" (or if
          empty, last path component of URL) because it is supposed to be relative to
          workspace root. This settings.xml file existence check fails build before maven
          is run.

          When configuring "Alternate settings file" field it seems same wrong validation
          is used to check for existence of configured file, and it doesn't complain when
          configured "Alternate settings" file path doesn't start with "Local module
          directory" (or if empty, last path component of URL).

          If one configures job's "Alternate settings file" path not to include "Local
          module directory", build starts (settings.xml file existence check seems to
          pass), but in build log I see that path used for -s option is wrong, it doesn't
          append "Local module directory" nor last path component of URL if "Local module
          directory" is empty; maven doesn't complain that -s option uses invalid path and
          just continues, but later build fails because alternate settings.xml hasn't been
          applied (e.g. dependency/plugin can not be downloaded from secured repository as
          appropriate server definition is missing).

          Current workaround is to explicitly specify -s option in "Goals and options",
          and as value use full absolute path to alternate settings file.

          Stevo Slavić added a comment - I'm experiencing similar issue related to alternate settings file feature in Hudson ver. 1.329 and after upgrade it has been reproduced in Hudson ver. 1.332 too. Help for "Alternate settings file" field suggests that path should be relative to workspace root; regardless if build's "Local module directory" is empty or not, when build starts Hudson seems to check for existence of configured settings.xml file but it does so using wrong file path: to the job workspace Hudson wrongfully appends "Local module directory" (if empty then it appends last path component of URL), and then appends path configured as "Alternate settings file" which already contains "Local module directory" (or if empty, last path component of URL) because it is supposed to be relative to workspace root. This settings.xml file existence check fails build before maven is run. When configuring "Alternate settings file" field it seems same wrong validation is used to check for existence of configured file, and it doesn't complain when configured "Alternate settings" file path doesn't start with "Local module directory" (or if empty, last path component of URL). If one configures job's "Alternate settings file" path not to include "Local module directory", build starts (settings.xml file existence check seems to pass), but in build log I see that path used for -s option is wrong, it doesn't append "Local module directory" nor last path component of URL if "Local module directory" is empty; maven doesn't complain that -s option uses invalid path and just continues, but later build fails because alternate settings.xml hasn't been applied (e.g. dependency/plugin can not be downloaded from secured repository as appropriate server definition is missing). Current workaround is to explicitly specify -s option in "Goals and options", and as value use full absolute path to alternate settings file.

          Stevo Slavić added a comment -

          Created an attachment (id=997)
          Patch which fixes doCheckFileInWorkspace and doCheckFileRelative checks instead of module root to use workspace file path; code duplication in both methods is not fixed.

          Stevo Slavić added a comment - Created an attachment (id=997) Patch which fixes doCheckFileInWorkspace and doCheckFileRelative checks instead of module root to use workspace file path; code duplication in both methods is not fixed.

          Andrew Bayer added a comment -

          Aaaah - I see the problem. Simpler than I thought. Lemme just write up a test to validate this and I'll commit it.

          Andrew Bayer added a comment - Aaaah - I see the problem. Simpler than I thought. Lemme just write up a test to validate this and I'll commit it.

          Stevo Slavić added a comment -

          I guess it wasn't that simple or you didn't have time yet.

          Stevo Slavić added a comment - I guess it wasn't that simple or you didn't have time yet.

          Logical added a comment -

          For the people that need a workaround:
          Add the -s option and the full path to the 'Goals' field, like: '-s C:\Users\user\.m2\settings.xml install'

          Logical added a comment - For the people that need a workaround: Add the -s option and the full path to the 'Goals' field, like: '-s C:\Users\user\.m2\settings.xml install'

          Andrew Bayer added a comment -

          Sorry for the delay - it'll be fixed in 1.350.

          Andrew Bayer added a comment - Sorry for the delay - it'll be fixed in 1.350.

          Code changed in hudson
          User: : abayer
          Path:
          trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSet.java
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/28278
          Log:
          [FIXED JENKINS-4693] Fixed handling of relative paths in alternate settings.xml in Maven 2 projects

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : abayer Path: trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSet.java trunk/www/changelog.html http://jenkins-ci.org/commit/28278 Log: [FIXED JENKINS-4693] Fixed handling of relative paths in alternate settings.xml in Maven 2 projects

          bouiaw added a comment -

          The fix for this issue caused the regression described at : http://n4.nabble.com/no-such-file-pom-xml-after-1-350-upgrade-td1594779.html#a1594779

          bouiaw added a comment - The fix for this issue caused the regression described at : http://n4.nabble.com/no-such-file-pom-xml-after-1-350-upgrade-td1594779.html#a1594779

          Code changed in hudson
          User: : abayer
          Path:
          trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSet.java
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/28942
          Log:
          [FIXED JENKINS-4693] Changed checkFileInWorkspace to look at getModuleRoot(), reverting to earlier behavior

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : abayer Path: trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSet.java trunk/www/changelog.html http://jenkins-ci.org/commit/28942 Log: [FIXED JENKINS-4693] Changed checkFileInWorkspace to look at getModuleRoot(), reverting to earlier behavior

          bimargulies added a comment - - edited

          As of 1.353, I'm still failing with this.

          here are the circumstances.

          My repository URL is:

          http://svn.basistech.net/engineering/rex2009/trunk/java

          When I enter a pathname relative to this location, I get a red indication. When I enter a pathname relative to 'trunk' (one level up from where it's supposed to be), I don't get a red indication. In both cases, it fails at runtime.

          The desired settings file is just sitting in that 'java' directory there.

          bimargulies added a comment - - edited As of 1.353, I'm still failing with this. here are the circumstances. My repository URL is: http://svn.basistech.net/engineering/rex2009/trunk/java When I enter a pathname relative to this location, I get a red indication. When I enter a pathname relative to 'trunk' (one level up from where it's supposed to be), I don't get a red indication. In both cases, it fails at runtime. The desired settings file is just sitting in that 'java' directory there.

          Andrew Bayer added a comment -

          What are you checking out? If your job is checking out http://svn.basistech.net/engineering/rex2009/trunk/java, and your alternate settings file is in the repo at http://svn.basistech.net/engineering/rex2009/trunk/java/altSettings.xml, then all you need to put in the "Alternate settings" field is "altSettings.xml". If you're checking out http://svn.basistech.net/engineering/rex2009/trunk, then you need to put in "java/altSettings.xml".

          Andrew Bayer added a comment - What are you checking out? If your job is checking out http://svn.basistech.net/engineering/rex2009/trunk/java , and your alternate settings file is in the repo at http://svn.basistech.net/engineering/rex2009/trunk/java/altSettings.xml , then all you need to put in the "Alternate settings" field is "altSettings.xml". If you're checking out http://svn.basistech.net/engineering/rex2009/trunk , then you need to put in "java/altSettings.xml".

          bimargulies added a comment -

          I tried that. It doesn't work.

          If I put in java/xxx.xml, hudson invokes maven with java/java/xxx.xml, and it fails.

          As of right now, the checkout URL is http://svn.basistech.net/engineering/perceptron-training/trunk

          If plain hudson-maven-settings.xml , I get:

          basis.snapshots due to an error: Error transferring file
          [INFO ] Repository 'basis.snapshots' will be blacklisted
          [trunk] $ /home/hudson/tools/JDK16/bin/java -Xmx512m -cp /home/hudson/maven-agent.jar:/home/hudson/tools/apache-maven-2.2.1/boot/classworlds-1.1.jar hudson.maven.agent.Main /home/hudson/tools/apache-maven-2.2.1 /home/hudson/slave.jar /home/hudson/maven-interceptor.jar 43747 /home/hudson/maven2.1-interceptor.jar
          <===[HUDSON REMOTING CAPACITY]===>channel started
          Executing Maven:  -B -f /home/hudson/workspace/rex-2009/trunk/pom.xml -Dmaven.repo.local=/home/hudson/workspace/rex-2009/.repository -s /home/hudson/workspace/rex-2009/hudson-maven-settings.xml clean install
          WARNING: Alternate user settings file: /home/hudson/workspace/rex-2009/hudson-maven-settings.xml is invalid. Using default path.
          

          If I put in trunk/hudson-maven-settings.xml

          I get an error that it cannot find trunk/trunk/hudson-maven-settings.xml. yes, two trunks.

          bimargulies added a comment - I tried that. It doesn't work. If I put in java/xxx.xml, hudson invokes maven with java/java/xxx.xml, and it fails. As of right now, the checkout URL is http://svn.basistech.net/engineering/perceptron-training/trunk If plain hudson-maven-settings.xml , I get: basis.snapshots due to an error: Error transferring file [INFO ] Repository 'basis.snapshots' will be blacklisted [trunk] $ /home/hudson/tools/JDK16/bin/java -Xmx512m -cp /home/hudson/maven-agent.jar:/home/hudson/tools/apache-maven-2.2.1/boot/classworlds-1.1.jar hudson.maven.agent.Main /home/hudson/tools/apache-maven-2.2.1 /home/hudson/slave.jar /home/hudson/maven-interceptor.jar 43747 /home/hudson/maven2.1-interceptor.jar <===[HUDSON REMOTING CAPACITY]===>channel started Executing Maven: -B -f /home/hudson/workspace/rex-2009/trunk/pom.xml -Dmaven.repo.local=/home/hudson/workspace/rex-2009/.repository -s /home/hudson/workspace/rex-2009/hudson-maven-settings.xml clean install WARNING: Alternate user settings file: /home/hudson/workspace/rex-2009/hudson-maven-settings.xml is invalid. Using default path. If I put in trunk/hudson-maven-settings.xml I get an error that it cannot find trunk/trunk/hudson-maven-settings.xml. yes, two trunks.

          bimargulies added a comment -

          Typical error in the second case:

          t revision 10914
          no change for http://svn.basistech.net/engineering/perceptron-training/trunk since the previous build
          Parsing POMs
          ERROR: No such settings file /home/hudson/workspace/rex-2009/trunk/trunk/hudson-maven-settings.xml exists
          Please verify that your alternate settings file is specified properly and exists in the workspace.
          

          bimargulies added a comment - Typical error in the second case: t revision 10914 no change for http://svn.basistech.net/engineering/perceptron-training/trunk since the previous build Parsing POMs ERROR: No such settings file /home/hudson/workspace/rex-2009/trunk/trunk/hudson-maven-settings.xml exists Please verify that your alternate settings file is specified properly and exists in the workspace.

          bimargulies added a comment -

          The help text for the settings file is part of this mess. It says:

          Specifies a path to an alternate settings.xml file for Maven. This is equivalent to the -s or --settings options on the Maven command line.

          This path is relative to the workspace root.

          Since an SVN URL of .whatever./trunk results in a subdirectory of the workspace directory named 'trunk', that would seem to imply that the right location to type in is 'trunk/hudson-maven-settings.xml'. But that results in trunk/trunk at runtime.

          bimargulies added a comment - The help text for the settings file is part of this mess. It says: Specifies a path to an alternate settings.xml file for Maven. This is equivalent to the -s or --settings options on the Maven command line. This path is relative to the workspace root. Since an SVN URL of .whatever./trunk results in a subdirectory of the workspace directory named 'trunk', that would seem to imply that the right location to type in is 'trunk/hudson-maven-settings.xml'. But that results in trunk/trunk at runtime.

          Andrew Bayer added a comment -

          Are you sure you're on 1.353? Because I know exactly the behavior you're describing, and that's what was fixed in 1.350 and later. I can't reproduce what you're seeing with 1.353, but I can with 1.349.

          Andrew Bayer added a comment - Are you sure you're on 1.353? Because I know exactly the behavior you're describing, and that's what was fixed in 1.350 and later. I can't reproduce what you're seeing with 1.353, but I can with 1.349.

          bimargulies added a comment -

          The bottom of the page says:

          Page generated: Apr 6, 2010 1:02:04 PMHudson ver. 1.353

          What else can I look at?

          bimargulies added a comment - The bottom of the page says: Page generated: Apr 6, 2010 1:02:04 PMHudson ver. 1.353 What else can I look at?

          Andrew Bayer added a comment - - edited

          That's a pretty good sign right there. =) Hrm. Let me keep poking around. Could you go to Manage Hudson->Manage Plugins->Installed and make sure you have version 1.353 of the Maven 2 Project Plugin installed? I don't know any reason why you wouldn't, but just to be sure.

          Andrew Bayer added a comment - - edited That's a pretty good sign right there. =) Hrm. Let me keep poking around. Could you go to Manage Hudson->Manage Plugins->Installed and make sure you have version 1.353 of the Maven 2 Project Plugin installed? I don't know any reason why you wouldn't, but just to be sure.

          bimargulies added a comment -

          First bad sign:

          You have data stored in an older format and/or unreadable data.

          I've never seen THAT before.

          bimargulies added a comment - First bad sign: You have data stored in an older format and/or unreadable data. I've never seen THAT before.

          bimargulies added a comment -
          Maven Integration plugin 1.353
          

          The is no 'Maven 2 Project Plugin'

          bimargulies added a comment - Maven Integration plugin 1.353 The is no 'Maven 2 Project Plugin'

          bimargulies added a comment -

          However, by poking around:

          Manifest-Version: 1.0
          Archiver-Version: Plexus Archiver
          Created-By: Apache Maven
          Built-By: kohsuke
          Build-Jdk: 1.6.0_19-fastdebug
          Extension-Name: maven-plugin
          Specification-Title: This plug-in provides deep integration of Hudson
           and Maven. This functionality used to be part of the Hudson core.  No
           w it is a plug-in that is installed by default, but can be disabled.
          Implementation-Title: maven-plugin
          Implementation-Version: 1.353
          Plugin-Class: hudson.maven.PluginImpl
          Short-Name: maven-plugin
          Long-Name: Maven Integration plugin
          Url: http://wiki.jenkins-ci.org/display/JENKINS/Maven+2+Project+Plugin
          Plugin-Version: 1.353
          Hudson-Version: 1.353
          Plugin-Developers:
          
          

          bimargulies added a comment - However, by poking around: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: kohsuke Build-Jdk: 1.6.0_19-fastdebug Extension-Name: maven-plugin Specification-Title: This plug-in provides deep integration of Hudson and Maven. This functionality used to be part of the Hudson core. No w it is a plug-in that is installed by default, but can be disabled. Implementation-Title: maven-plugin Implementation-Version: 1.353 Plugin-Class: hudson.maven.PluginImpl Short-Name: maven-plugin Long-Name: Maven Integration plugin Url: http://wiki.jenkins-ci.org/display/JENKINS/Maven+2+Project+Plugin Plugin-Version: 1.353 Hudson-Version: 1.353 Plugin-Developers:

          bimargulies added a comment -

          Another hint: I tried moving the settings file to another piece of svn tree. The incorrect pathname that resulted was

          WORKSPACE_ROOT/FIRST_MODULE_NAME/SECOND_MODULE_NAME/whatever.xml

          instead of:

          WORKSPACE_ROOT/SECOND_MODULE_NAME/whatever.xml

          bimargulies added a comment - Another hint: I tried moving the settings file to another piece of svn tree. The incorrect pathname that resulted was WORKSPACE_ROOT/FIRST_MODULE_NAME/SECOND_MODULE_NAME/whatever.xml instead of: WORKSPACE_ROOT/SECOND_MODULE_NAME/whatever.xml

          bimargulies added a comment -

          ping?

          bimargulies added a comment - ping?

          Code changed in hudson
          User: : abayer
          Path:
          trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java
          http://jenkins-ci.org/commit/34950
          Log:
          JENKINS-4693 Systematized Maven alternate settings logic - consistent in both POM parsing and actual Maven command line.

          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 http://jenkins-ci.org/commit/34950 Log: JENKINS-4693 Systematized Maven alternate settings logic - consistent in both POM parsing and actual Maven command line.

          Code changed in hudson
          User: : abayer
          Path:
          trunk/www/changelog.html
          http://jenkins-ci.org/commit/34951
          Log:
          Fix for JENKINS-4693

          SCM/JIRA link daemon added a comment - Code changed in hudson User: : abayer Path: trunk/www/changelog.html http://jenkins-ci.org/commit/34951 Log: Fix for JENKINS-4693

          Andrew Bayer added a comment -

          Ok -I think I've finally got it. I've made sure that both places the alternate settings file gets used (POM parsing and Maven execution), the same logic is used to determine the settings file location. It'll first check if the alternate settings value is an absolute path (which shouldn't be possible to do through the UI, but just to be safe...). If not, it'll check for the alternate settings file in getWorkspace() (i.e., WORKSPACE_ROOT/whatever.xml), and then in getModuleRoot() (i.e., WORKSPACE_ROOT/FIRST_MODULE_NAME/whatever.xml). This fix won't be in a release until 1.378, but you can download the war file from http://ci.hudson-labs.org/job/hudson_main_trunk/ and test it - just make sure the most recent successful build is 272 or higher.

          Andrew Bayer added a comment - Ok -I think I've finally got it. I've made sure that both places the alternate settings file gets used (POM parsing and Maven execution), the same logic is used to determine the settings file location. It'll first check if the alternate settings value is an absolute path (which shouldn't be possible to do through the UI, but just to be safe...). If not, it'll check for the alternate settings file in getWorkspace() (i.e., WORKSPACE_ROOT/whatever.xml), and then in getModuleRoot() (i.e., WORKSPACE_ROOT/FIRST_MODULE_NAME/whatever.xml). This fix won't be in a release until 1.378, but you can download the war file from http://ci.hudson-labs.org/job/hudson_main_trunk/ and test it - just make sure the most recent successful build is 272 or higher.

          dogfood added a comment -

          Integrated in hudson_main_trunk #273
          JENKINS-4693 Systematized Maven alternate settings logic - consistent in both POM parsing and actual Maven command line.

          Current behavior as of this change:

          • If project.getAlternateSettings() is absolute, just use the absolute path - this may not actually work through the configuration UI, but I put it in to be safe.
          • else, if project.getAlternateSettings() exists in getWorkspace(), use that
          • else, if project.getAlternateSettings() exists in getModuleRoot(), use that
          • else null - don't use an alternate settings location

          abayer :
          Files :

          • /trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java

          dogfood added a comment - Integrated in hudson_main_trunk #273 JENKINS-4693 Systematized Maven alternate settings logic - consistent in both POM parsing and actual Maven command line. Current behavior as of this change: If project.getAlternateSettings() is absolute, just use the absolute path - this may not actually work through the configuration UI, but I put it in to be safe. else, if project.getAlternateSettings() exists in getWorkspace(), use that else, if project.getAlternateSettings() exists in getModuleRoot(), use that else null - don't use an alternate settings location abayer : Files : /trunk/hudson/main/maven-plugin/src/main/java/hudson/maven/MavenModuleSetBuild.java

          Stevo Slavić added a comment -

          Just installed 1.378, regular maven build now works, thanks! But, Sonar plugin is broken now - relative path to alternate settings.xml file is being passed to the plugin. Here is snippet of build log:

          ...
          [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 9 minutes 7 seconds [INFO] Finished at: Sun Sep 26 16:30:31 CEST 2010
          [INFO] Final Memory: 138M/812M [INFO] ------------------------------------------------------------------------ channel stopped
          [trunk] $ /var/lib/hudson/tools/Apache_Maven_2.2.1/bin/mvn -f pom.xml -s trunk/settings.xml -e -B sonar:sonar -Dsonar.jdbc.driver=com.mysql.jdbc.Driver -Dsonar.jdbc.url=jdbc:mysql://db.foo.bar:3306/sonar?useUnicode=true&characterEncoding=utf8 -Dsonar.host.url=http://sonar.foo.bar + Error stacktraces are turned on.
          WARNING: Alternate user settings file: trunk/settings.xml is invalid. Using default path. 
          ...
          

          Not sure if this is hudson sonar plugin issue or the fix is not complete.

          Stevo Slavić added a comment - Just installed 1.378, regular maven build now works, thanks! But, Sonar plugin is broken now - relative path to alternate settings.xml file is being passed to the plugin. Here is snippet of build log: ... [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 9 minutes 7 seconds [INFO] Finished at: Sun Sep 26 16:30:31 CEST 2010 [INFO] Final Memory: 138M/812M [INFO] ------------------------------------------------------------------------ channel stopped [trunk] $ / var /lib/hudson/tools/Apache_Maven_2.2.1/bin/mvn -f pom.xml -s trunk/settings.xml -e -B sonar:sonar -Dsonar.jdbc.driver=com.mysql.jdbc.Driver -Dsonar.jdbc.url=jdbc:mysql: //db.foo.bar:3306/sonar?useUnicode= true &characterEncoding=utf8 -Dsonar.host.url=http://sonar.foo.bar + Error stacktraces are turned on. WARNING: Alternate user settings file: trunk/settings.xml is invalid. Using default path. ... Not sure if this is hudson sonar plugin issue or the fix is not complete.

          Stevo Slavić added a comment -

          Also, there is typo in 1.378 changelog, JENKINS-4963 issue is being referred to instead of JENKINS-4693.

          Stevo Slavić added a comment - Also, there is typo in 1.378 changelog, JENKINS-4963 issue is being referred to instead of JENKINS-4693 .

          Stevo Slavić added a comment -

          Hudson doesn't work as described behavior and this is still not fixed. When configuring build alternate settings.xml file validation fails in all cases except in case when alternate settings.xml file path is given relative to workspace root. If configured so plugins like sonar fail to access alternate settings.xml file since they are being run from (first) module root (notice "[trunk]" in sonar execution log snippet above).

          Stevo Slavić added a comment - Hudson doesn't work as described behavior and this is still not fixed. When configuring build alternate settings.xml file validation fails in all cases except in case when alternate settings.xml file path is given relative to workspace root. If configured so plugins like sonar fail to access alternate settings.xml file since they are being run from (first) module root (notice " [trunk] " in sonar execution log snippet above).

          EmDauPhu added a comment - - edited

          Also I noticed that the maven2 jobs are checking poms before running any maven goals.

          I have some jobs configured with the "-s" option in the "goals & options" field and they fail because the wrong settings file is used. Alternative settings.xml is noticed from this field and as there's nothing specified in the appropriate field, the one in ".m2" or the global one is taken instead.

          I'll reconfigure my jobs but I think this should be considered as the path to the settings file is sometimes not very related to the job itself.
          I noticed that after upgrading from 1.36x to 1.379. I think the 1.378 and #4963 has something to do.

          EmDauPhu added a comment - - edited Also I noticed that the maven2 jobs are checking poms before running any maven goals. I have some jobs configured with the "-s" option in the "goals & options" field and they fail because the wrong settings file is used. Alternative settings.xml is noticed from this field and as there's nothing specified in the appropriate field, the one in ".m2" or the global one is taken instead. I'll reconfigure my jobs but I think this should be considered as the path to the settings file is sometimes not very related to the job itself. I noticed that after upgrading from 1.36x to 1.379. I think the 1.378 and #4963 has something to do.

          Stevo Slavić added a comment -

          Hudson sonar plugin seems to get relative path to alternate settings.xml, relative from workspace root (so as configured for the build job), but sonar plugin is running from module root. This doesn't seem to be the case with hudson maven plugin which prints out absolute path to alternate settings.xml as being used so it's not a problem that maven is run from module root. Not sure if (sonar) plugin needs to be adjusted because of changes to plugin API behavior or it's a bug in plugin API changes because they broke backward compatibility for passing configured alternate settings.xml path to the plugins.

          [1] maven plugin execution

          [trunk] $ /usr/lib64/jvm/java/bin/java -cp /var/lib/hudson/maven3-agent.jar:/var/lib/hudson/tools/Apache_Maven_3.0/boot/plexus-classworlds-2.2.3.jar org.jvnet.hudson.maven3.agent.Maven3Main /var/lib/hudson/tools/Apache_Maven_3.0 /var/lib/hudson/slave.jar /var/lib/hudson/maven3-interceptor.jar 37943
          <===[HUDSON REMOTING CAPACITY]===>���channel started
          Executing Maven: -B -f /var/lib/hudson/workspace/BuildJob/trunk/pom.xml -s /var/lib/hudson/workspace/BuildJob/trunk/settings.xml verify deploy

          [2] sonar plugin execution

          [trunk] $ /var/lib/hudson/tools/Apache_Maven_3.0/bin/mvn -f "/var/lib/hudson/workspace/BuildJob/trunk/pom.xml" -s trunk/settings.xml -e -B sonar:sonar -Dsonar.jdbc.driver=com.mysql.jdbc.Driver -Dsonar.jdbc.url=jdbc:mysql://sonar.foo.bar:3306/sonar?useUnicode=true&characterEncoding=utf8 ******** ******** -Dsonar.host.url=http://sonar.foo.bar:9000

          Stevo Slavić added a comment - Hudson sonar plugin seems to get relative path to alternate settings.xml, relative from workspace root (so as configured for the build job), but sonar plugin is running from module root. This doesn't seem to be the case with hudson maven plugin which prints out absolute path to alternate settings.xml as being used so it's not a problem that maven is run from module root. Not sure if (sonar) plugin needs to be adjusted because of changes to plugin API behavior or it's a bug in plugin API changes because they broke backward compatibility for passing configured alternate settings.xml path to the plugins. [1] maven plugin execution [trunk] $ /usr/lib64/jvm/java/bin/java -cp /var/lib/hudson/maven3-agent.jar:/var/lib/hudson/tools/Apache_Maven_3.0/boot/plexus-classworlds-2.2.3.jar org.jvnet.hudson.maven3.agent.Maven3Main /var/lib/hudson/tools/Apache_Maven_3.0 /var/lib/hudson/slave.jar /var/lib/hudson/maven3-interceptor.jar 37943 <=== [HUDSON REMOTING CAPACITY] ===>���channel started Executing Maven: -B -f /var/lib/hudson/workspace/BuildJob/trunk/pom.xml -s /var/lib/hudson/workspace/BuildJob/trunk/settings.xml verify deploy [2] sonar plugin execution [trunk] $ /var/lib/hudson/tools/Apache_Maven_3.0/bin/mvn -f "/var/lib/hudson/workspace/BuildJob/trunk/pom.xml" -s trunk/settings.xml -e -B sonar:sonar -Dsonar.jdbc.driver=com.mysql.jdbc.Driver -Dsonar.jdbc.url=jdbc:mysql://sonar.foo.bar:3306/sonar?useUnicode=true&characterEncoding=utf8 ******** ******** -Dsonar.host.url= http://sonar.foo.bar:9000

          Stevo Slavić added a comment -

          Couldn't jenkins just pass to plugins absolute path to configured alternate settings.xml file, so it doesn't matter from where (from which working directory) plugin (like sonar) runs from?

          Stevo Slavić added a comment - Couldn't jenkins just pass to plugins absolute path to configured alternate settings.xml file, so it doesn't matter from where (from which working directory) plugin (like sonar) runs from?

            Unassigned Unassigned
            wokkel wokkel
            Votes:
            11 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated: