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

m2 release fails on Windows using pure java subversion scm provider

      When I try to perform a maven release of a multi-module project using the com.google.code.maven-scm-provider-svnjava:maven-scm-provider-svnjava:1.12 provider the subversion checkin step fails with the following error

      [INFO] Checking in modified POMs...
      [INFO] SVN commit directory: c:\richm\hudson\slave\workspace\mvn-release-test
      [JENKINS] Archiving c:\richm\hudson\slave\workspace\mvn-release-test\pom.xml to /var/lib/jenkins/jobs/mvn-release-test/modules/uk.org.oldelvet.test$mvn-release-test/builds/2011-04-04_23-56-44/archive/uk.org.oldelvet.test/mvn-release-test/1.17-SNAPSHOT/pom.xml
      [INFO] ------------------------------------------------------------------------
      [ERROR] BUILD FAILURE
      [INFO] ------------------------------------------------------------------------
      [INFO] Unable to commit files
      Provider message:
      SVN commit failed.
      Command output:
      svn: 'c:\richm\hudson\slave\workspace\mvn-release-test\C:' is not a working copy
      [INFO] ------------------------------------------------------------------------

      The same release from the windows commandline and on linux works fine.

      After a bit of investigation I have identified the cause of the problem (and an easy workaround).

      Basically it seems that svnkit requires that it be passed the canonical names of files to be passed to it. In my case the path begins "c:" and svnkit confuses this with "C:" and gets confused. I can workaround/fix this easily by altering my windows slave configuration to use a pathname beginning with a capital C and all works fine.

      Ideally it would be nice to fix this because the error was confusing and I did have to do quite a lot of investigation in the maven-scm-provider-svnjava code to find some clues as to the problem and the workaround.

      I have investigated this using Jenkins 1.405 but know it was present in a few earlier builds.

      Attached is a sample maven project that fails along with a full log of a failing build.

          [JENKINS-9268] m2 release fails on Windows using pure java subversion scm provider

          Olivier Lamy added a comment -

          looks more a maven issue.
          I wonder if you are using cygwin ?
          If yes have a look here http://maven.apache.org/scm/subversion.html @bottom

          Olivier Lamy added a comment - looks more a maven issue. I wonder if you are using cygwin ? If yes have a look here http://maven.apache.org/scm/subversion.html @bottom

          You are correct that it is likely to be a maven issue although maven on the commandline does not suffer from the same problem. I suspect that is because the OS gives maven a canonical pathname when it gets invoked though.

          I am not using cygwin (indeed I tried using the pure java subversion scm provider in maven to alleviate the need to setup a subversion commandline on each of my slaves.

          I think that the key difference between a broken and working build is the maven commandline that is reported.

          Broken:

          Executing Maven: -B -f c:\richm\hudson\slave\workspace\mvn-release-test\pom.xml -Dpassword=********* -Dusername=someone -Dresume=false release:prepare release:perform

          Working:

          Executing Maven: -B -f C:\richm\hudson\slave\workspace\mvn-release-test\pom.xml -Dpassword=********* -Dusername=richm -Dresume=false release:prepare release:perform

          Actually I just tried mvn on the commandline with my sample "broken" project specifying -f explictly and using a lowercase c: and that fails too.

          I suspect that jenkins could "fix" this issue by using getCanonicalPath() when invoking maven. Whether or not that is the most appropriate fix I could not say.

          Richard Mortimer added a comment - You are correct that it is likely to be a maven issue although maven on the commandline does not suffer from the same problem. I suspect that is because the OS gives maven a canonical pathname when it gets invoked though. I am not using cygwin (indeed I tried using the pure java subversion scm provider in maven to alleviate the need to setup a subversion commandline on each of my slaves. I think that the key difference between a broken and working build is the maven commandline that is reported. Broken: Executing Maven: -B -f c:\richm\hudson\slave\workspace\mvn-release-test\pom.xml -Dpassword=********* -Dusername=someone -Dresume=false release:prepare release:perform Working: Executing Maven: -B -f C:\richm\hudson\slave\workspace\mvn-release-test\pom.xml -Dpassword=********* -Dusername=richm -Dresume=false release:prepare release:perform Actually I just tried mvn on the commandline with my sample "broken" project specifying -f explictly and using a lowercase c: and that fails too. I suspect that jenkins could "fix" this issue by using getCanonicalPath() when invoking maven. Whether or not that is the most appropriate fix I could not say.

          James Nord added a comment -

          As this is all handled by the Maven2 plugin and not m2release moving the issue to maven2 plugin (although it really seems like a core apache maven issue or one of it's plugins to me.)

          James Nord added a comment - As this is all handled by the Maven2 plugin and not m2release moving the issue to maven2 plugin (although it really seems like a core apache maven issue or one of it's plugins to me.)

          James Nord added a comment -

          Note the workspace on windows could also be on a case sensitive filesystem (rather than the default case insensitive case preserving -think CIFS server).

          Doing this every build seems a bit like a waste - and I have hit this issue elsewhere (but don't recall the exact issue)

          Perhaps a better fix would be to check the remotefs root when configuring the slave and provide a warning, or to convert the slave root

          James Nord added a comment - Note the workspace on windows could also be on a case sensitive filesystem (rather than the default case insensitive case preserving -think CIFS server). Doing this every build seems a bit like a waste - and I have hit this issue elsewhere (but don't recall the exact issue) Perhaps a better fix would be to check the remotefs root when configuring the slave and provide a warning, or to convert the slave root

            Unassigned Unassigned
            oldelvet Richard Mortimer
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: