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

"default maven" should try to sniff the workspace to determine the maven version

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Platform: All, OS: All

      I discovered this when trying to make hudson eat my own dog food (compiling the
      plugins I'm messing with)

      When running a Maven 2.0.4 based build on *nix, Hudson attempts to spawn a
      process using the wrong script, "maven". Maven2 comes only with one script that
      can be used to launch maven, its named "mvn". The windows batch file is named
      "mvn.bat".

      There are m2 and m2.bat files as well, but these will fail immediately and tell
      you to run mvn or mvn.bat.

      One solution might be that if the "maven" or "maven.bat" files can't be found,
      then "mvn" or "mvn.bat" should be used.

      Console Output:

      [trunk] $ maven test
      FATAL: command execution failed
      java.io.IOException: Cannot run program "maven" (in directory
      "/whatever/hudson/jobs/FindBugsPlugin/workspace/trunk"): java.io.IOException:
      error=2, No such file or directory
      at java.lang.ProcessBuilder.start(ProcessBuilder.java:459)
      at java.lang.Runtime.exec(Runtime.java:593)
      at hudson.Proc$LocalProc.<init>(Proc.java:79)
      at hudson.Launcher$LocalLauncher.launch(Launcher.java:130)
      at hudson.Launcher.launch(Launcher.java:74)
      at hudson.Launcher.launch(Launcher.java:70)
      at hudson.Launcher.launch(Launcher.java:58)
      at hudson.tasks.Maven.perform(Maven.java:94)
      at hudson.model.Build$RunnerImpl.build(Build.java:251)
      at hudson.model.Build$RunnerImpl.doRun(Build.java:223)
      at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:114)
      at hudson.model.Run.run(Run.java:533)
      at hudson.model.Build.run(Build.java:203)
      at hudson.model.Executor.run(Executor.java:61)
      Caused by: java.io.IOException: java.io.IOException: error=2, No such file or
      directory
      at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
      at java.lang.ProcessImpl.start(ProcessImpl.java:65)
      at java.lang.ProcessBuilder.start(ProcessBuilder.java:452)
      ... 13 more
      finished: FAILURE

          [JENKINS-273] "default maven" should try to sniff the workspace to determine the maven version

          crahen added a comment -

          When testing my suggested fix, I simply copied $MVN_HOME/bin/mvn to
          $MVN_HOME/bin/maven. I saw the same output. It looks like the Maven builder is
          not respecting the MVN_HOME variable and expects the command to be in the
          workplace directory for the project being built.

          Is it possible to make the Maven builder run the correct $MVN_HOME/bin/mvn command?

          crahen added a comment - When testing my suggested fix, I simply copied $MVN_HOME/bin/mvn to $MVN_HOME/bin/maven. I saw the same output. It looks like the Maven builder is not respecting the MVN_HOME variable and expects the command to be in the workplace directory for the project being built. Is it possible to make the Maven builder run the correct $MVN_HOME/bin/mvn command?

          crahen added a comment -

          Just for the heck of it, I checked in a script named "maven" into my project
          root since thats where I thought Hudson was looking for maven. Same error. I'm
          not sure where it could be looking, but its not $MVN_HOME/bin

          I double checked the MVN_HOME I have configured, and its correct. No trailing
          slashes or anything strange. If you need anything else let me know.

          crahen added a comment - Just for the heck of it, I checked in a script named "maven" into my project root since thats where I thought Hudson was looking for maven. Same error. I'm not sure where it could be looking, but its not $MVN_HOME/bin I double checked the MVN_HOME I have configured, and its correct. No trailing slashes or anything strange. If you need anything else let me know.

          This is actually by design. If you do a system configuration and specifies the
          maven location, Hudson will be able to tell if it's M1 or M2, and does the right
          thing.

          But when you leave it up to "default maven", then Hudson can't really tell if
          it's M1 or M2, so we are hard-coding it to run M1, and assume it's in the PATH.

          Perhaps we can improve the logic by sniffing the pom.xml/project.xml in the
          workspace, but generally speaking it's impossible to get this correct in all cases.

          Kohsuke Kawaguchi added a comment - This is actually by design. If you do a system configuration and specifies the maven location, Hudson will be able to tell if it's M1 or M2, and does the right thing. But when you leave it up to "default maven", then Hudson can't really tell if it's M1 or M2, so we are hard-coding it to run M1, and assume it's in the PATH. Perhaps we can improve the logic by sniffing the pom.xml/project.xml in the workspace, but generally speaking it's impossible to get this correct in all cases.

          crahen added a comment -

          Ok, I was under the mistaken impression that Default would make a best effort to
          select a maven. I figured since I'd configured only 1 maven installation it
          would be the only sane default. Maybe we should label (Default) as (System) or
          put a note somewhere about how it will try to run maven?

          Selecting my maven installation explicitly did the trick.

          I have a follow-on question; I run my Hudson instance in a restricted
          environment. Maven by default tries to stick a bunch of stuff in a ~/.m2. I
          actually don't want anything going in ~/.m2 for a number of reasons, instead I
          would like to control where this goes. I should be able to do this from teh
          commandline using "mvn -Duser.home=/tmp/something" since Maven resolves ~/m2
          using the user.home property. Does the maven goal field work the same way as the
          ant target field where whatever I enter in that box will just all be passed
          along as the full command line to mvn?

          (I imagine this might be a more general issue for typical hudson users as well.
          Several simultaneous builds might all clobber the ~/.m2 directory contents at
          the same time)

          Reason: Error getting POM for 'org.jvnet.hudson.tools:maven-hpi-plugin' from the
          repository: Specified destination directory cannot be created:
          /.m2/repository/org/jvnet/hudson/tools/maven-hpi-plugin/1.2
          org.jvnet.hudson.tools:maven-hpi-plugin:pom:1.2

          crahen added a comment - Ok, I was under the mistaken impression that Default would make a best effort to select a maven. I figured since I'd configured only 1 maven installation it would be the only sane default. Maybe we should label (Default) as (System) or put a note somewhere about how it will try to run maven? Selecting my maven installation explicitly did the trick. — I have a follow-on question; I run my Hudson instance in a restricted environment. Maven by default tries to stick a bunch of stuff in a ~/.m2. I actually don't want anything going in ~/.m2 for a number of reasons, instead I would like to control where this goes. I should be able to do this from teh commandline using "mvn -Duser.home=/tmp/something" since Maven resolves ~/m2 using the user.home property. Does the maven goal field work the same way as the ant target field where whatever I enter in that box will just all be passed along as the full command line to mvn? (I imagine this might be a more general issue for typical hudson users as well. Several simultaneous builds might all clobber the ~/.m2 directory contents at the same time) Reason: Error getting POM for 'org.jvnet.hudson.tools:maven-hpi-plugin' from the repository: Specified destination directory cannot be created: /.m2/repository/org/jvnet/hudson/tools/maven-hpi-plugin/1.2 org.jvnet.hudson.tools:maven-hpi-plugin:pom:1.2

          crahen added a comment -

          To answer my own follow on, the answer is yes, I can just stick a
          -Duser.home=/whatever into my maven goals.

          crahen added a comment - To answer my own follow on, the answer is yes, I can just stick a -Duser.home=/whatever into my maven goals.

          The help text on maven mentions that you can specify options, although it's bit
          subtle. If you have a better wording suggestion please let me know.

          I'm changing the subject to reflect the task.

          Kohsuke Kawaguchi added a comment - The help text on maven mentions that you can specify options, although it's bit subtle. If you have a better wording suggestion please let me know. I'm changing the subject to reflect the task.

          Fixed in 1.81.

          Kohsuke Kawaguchi added a comment - Fixed in 1.81.

            Unassigned Unassigned
            crahen crahen
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved: