• 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

          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: