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

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.

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

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)

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, 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...

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