• 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

          wokkel created issue -

          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 made changes -
          Assignee New: Andrew Bayer [ abayer ]

          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.
          mdonohue made changes -
          Link New: This issue is duplicated by JENKINS-4938 [ JENKINS-4938 ]
          mdonohue made changes -
          Link New: This issue is blocking JENKINS-4939 [ JENKINS-4939 ]

          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.

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

              Created:
              Updated: