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

Tool can not find maven - log message missleading

    XMLWordPrintable

Details

    • pipeline-maven-3.11.0

    Description

      in a clean jenkins (no maven plugin installed)

      In an agent without maven on the path add MAVEN_HOME to the environment variables for the node.

       

      run the follwoing pipeline

      node {
          bat "set"
          withMaven {
              git changelog: false, poll: false, url: 'https://github.com/jtnord/maven-test-project.git'
              
              bat "mvn package"
          }
      }
      

      This should work as MAVEN_HOME is in the environment as confimerd by the set command.

      However it fails with the following message

      [withMaven] use JDK installation provided by the build agent
      $ where mvn.cmd
      $ where mvn.bat
      [withMaven] use Maven installation provided by the build agent with executable null
      [Pipeline] // withMaven
      [Pipeline] }
      [Pipeline] // node
      [Pipeline] End of Pipeline
      ERROR: Could not find maven executable, please set up a Maven Installation or configure MAVEN_HOME or M2_HOME environment variable

      But MAVEN_HOME is defined - so this is just plain wrong...

       

      Attachments

        Issue Links

          Activity

            Here is another failing sample.
            But in my case I have the global tools defined with the auto install option selected.

            pipeline {
                agent any
                tools {
                    maven 'apache-maven-3.3.9'
                    jdk 'jdk8'
                }
                stages {
                    stage('Build') {
                        steps {
                            sh 'printenv'
                            withMaven(mavenSettingsConfig: 'maven-settings-global') {
                                sh 'mvn clean package'
                            }
                        }
                    }     
                }    
            }
            

            Using the command printenv it's possible confirm that the environment variable M2_HOME was already defined before the execution of the pipeline-maven-plugin.

            M2_HOME=/home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/apache-maven-3.3.9
            
            mtocchetto Marcelo Tocchetto added a comment - Here is another failing sample. But in my case I have the global tools defined with the auto install option selected. pipeline { agent any tools { maven 'apache-maven-3.3.9' jdk 'jdk8' } stages { stage('Build') { steps { sh 'printenv' withMaven(mavenSettingsConfig: 'maven-settings-global') { sh 'mvn clean package' } } } } } Using the command printenv it's possible confirm that the environment variable M2_HOME was already defined before the execution of the pipeline-maven-plugin . M2_HOME=/home/jenkins/tools/hudson.tasks.Maven_MavenInstallation/apache-maven-3.3.9

            I have a similar problem with Maven installations created through the Pipeline Project-Env Plugin.

            I could imagine that the Maven installation is not recognized, because the env vars are read directly from the computer on which the build is running, instead reading the env vars through StepContext.get(EnvVars.class): https://github.com/jenkinsci/pipeline-maven-plugin/blob/e75e61a4dcbb961f073f081b3ab9282a42de87c4/jenkins-plugin/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L484

            repolevedavaj Jonas Bamberger added a comment - I have a similar problem with Maven installations created through the Pipeline Project-Env Plugin . I could imagine that the Maven installation is not recognized, because the env vars are read directly from the computer on which the build is running, instead reading the env vars through StepContext.get(EnvVars.class) : https://github.com/jenkinsci/pipeline-maven-plugin/blob/e75e61a4dcbb961f073f081b3ab9282a42de87c4/jenkins-plugin/src/main/java/org/jenkinsci/plugins/pipeline/maven/WithMavenStepExecution2.java#L484
            davidnewcomb David Newcomb added a comment - - edited

            We have just taken a Jenkins update which has broken every maven build we have

            This is marked as "Fixed but not released", so when is it going to be released?

            Stackoverflow et al are saying don't use withMaven, switch to using withEnv instead, see https://stackoverflow.com/questions/42691946/maven-tool-is-not-set-in-jenkins-pipeline

            Even though this was from 5 years ago there were not many after that until Dec 2019 and they are starting to appear again, presumably as people upgrade on to this release.

            But I'd rather continue to use withMaven though.

            davidnewcomb David Newcomb added a comment - - edited We have just taken a Jenkins update which has broken every maven build we have This is marked as "Fixed but not released", so when is it going to be released? Stackoverflow et al are saying don't use withMaven, switch to using withEnv instead, see https://stackoverflow.com/questions/42691946/maven-tool-is-not-set-in-jenkins-pipeline Even though this was from 5 years ago there were not many after that until Dec 2019 and they are starting to appear again, presumably as people upgrade on to this release. But I'd rather continue to use withMaven though.
            teilo James Nord added a comment -

            aheritier are you planning a release - there seem to be quite a few unlreleased changes (and the plugin is not using CD for releases)

            teilo James Nord added a comment - aheritier are you planning a release - there seem to be quite a few unlreleased changes (and the plugin is not using CD for releases)
            teilo James Nord added a comment -

            FWIW I would generally recommend not relying on a java/maven version defined on the host but to manage that as part of the build (by passing it to the .

            You can also use tool installers to configure the location of maven that are no-ops , by just specifying the path to maven (and if it is different between agents due to windows/nix etc, use multiple installers and a conditional to select) or by setting up your agents with the installer local (and already installed in the right location) (so it only falls back to downloading something if the agent definition becomes older).

            The maintainers are currently on holiday - I will try and reach them when they return.

            In the interim as you are aufait with maven you can always download the source and build locally (mvn pacakge -DskipTests) and install the resulting hpi file.
            https://github.com/jenkinsci/pipeline-maven-plugin (you may have to update some other plugins in your jenkins instance)

            teilo James Nord added a comment - FWIW I would generally recommend not relying on a java/maven version defined on the host but to manage that as part of the build (by passing it to the . You can also use tool installers to configure the location of maven that are no-ops , by just specifying the path to maven (and if it is different between agents due to windows/nix etc, use multiple installers and a conditional to select) or by setting up your agents with the installer local (and already installed in the right location) (so it only falls back to downloading something if the agent definition becomes older). The maintainers are currently on holiday - I will try and reach them when they return. In the interim as you are aufait with maven you can always download the source and build locally ( mvn pacakge -DskipTests ) and install the resulting hpi file. https://github.com/jenkinsci/pipeline-maven-plugin (you may have to update some other plugins in your jenkins instance)
            davidnewcomb David Newcomb added a comment -

            Many thanks. I think the problem was that we didn't need a tools section before and now we do and it caught us off guard.

            Once I'd got the Maven installations set up in Jenkins so that it was downloading the correct version of Maven (as part of the pipeline) I found that JAVA_HOME was not being set. Maybe this would have been set if I added a JDK to the Jenkins configuration but we use Java11 and it is not possible to add a platform folder as the java home. (You have to install from zip or from Oracle+license etc). For that I had to add a global environment variable for JAVA_HOME which seemed a bit disconnected but this is probably going slightly off-topic as it's not strictly part of withMaven; however withMaven gets a bit confused if JAVA_HOME is not set properly.

            Thanks for the tip about building it myself, I will look into that.

            davidnewcomb David Newcomb added a comment - Many thanks. I think the problem was that we didn't need a tools section before and now we do and it caught us off guard. Once I'd got the Maven installations set up in Jenkins so that it was downloading the correct version of Maven (as part of the pipeline) I found that JAVA_HOME was not being set. Maybe this would have been set if I added a JDK to the Jenkins configuration but we use Java11 and it is not possible to add a platform folder as the java home. (You have to install from zip or from Oracle+license etc). For that I had to add a global environment variable for JAVA_HOME which seemed a bit disconnected but this is probably going slightly off-topic as it's not strictly part of withMaven; however withMaven gets a bit confused if JAVA_HOME is not set properly. Thanks for the tip about building it myself, I will look into that.

            teilo I would prefer to let the ne‹ maintainer bguerin doing it if possible

            But I agree we should release it ASAP

            aheritier Arnaud Héritier added a comment - teilo I would prefer to let the ne‹ maintainer bguerin doing it if possible But I agree we should release it ASAP

            aheritier, bguerin, is there any update on building the release? In my point of view it would make sense to switch to the automatic CI/CD pipeline of Jenkins to prevent having to relay on the maintainers to get a release. Building a release temporarily is acceptable as a short term solution, but at some point an official release should follow...

            repolevedavaj Jonas Bamberger added a comment - aheritier , bguerin , is there any update on building the release? In my point of view it would make sense to switch to the automatic CI/CD pipeline of Jenkins to prevent having to relay on the maintainers to get a release. Building a release temporarily is acceptable as a short term solution, but at some point an official release should follow...
            bguerin Benoit added a comment -

            Hello here,

            Sorry for being silent so long, I had no spare time last months ...

            > In my point of view it would make sense to switch to the automatic CI/CD pipeline of Jenkins

            Totaly agree, it is on my todo list, I just would like to increase the test coverage first

            aheritier do you have some time in the coming days to teach me how to release ?

            bguerin Benoit added a comment - Hello here, Sorry for being silent so long, I had no spare time last months ... > In my point of view it would make sense to switch to the automatic CI/CD pipeline of Jenkins Totaly agree, it is on my todo list, I just would like to increase the test coverage first aheritier do you have some time in the coming days to teach me how to release ?

            Yes @bguerin. We can do it next week if you want. Just send me an email to aheritier AT Apache DOT org

            aheritier Arnaud Héritier added a comment - Yes @bguerin. We can do it next week if you want. Just send me an email to aheritier AT Apache DOT org

            People

              bguerin Benoit
              teilo James Nord
              Votes:
              5 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: