Issues while deploying Mulesoft APIS through AZURE Devops pipeline due to Apache Maven Plugin version update to 3.10.0. in Azure devops agent

Sarkar, Sagar 0 Reputation points
2026-10-09T09:27:02.55+00:00

We are experiencing a build failure during the Maven build process. Initially, the build was failing while executing org.mule.tools.maven:mule-maven-plugin:4.3.1:process-sources. As part of troubleshooting, we updated the mule-maven-plugin version in the parent POM from 4.3.1 to 4.6.0 and confirmed that the application is inheriting the updated parent POM configuration. The build now references mule-maven-plugin 4.6.0, which confirms that the parent POM changes are being picked up correctly. However, the build continues to fail during the same phase even after the plugin upgrade. This indicates that the issue is not related to the plugin version inheritance.

After connecting to Mulesoft Support they confirmed the issue is observed following the automated Azure DevOps pipeline update to Apache Maven 3.10.0. Based on our compatibility checks, the current Mule Maven Plugin (MMP) releases support Maven versions ranging from 3.9.0 to 3.9.15, and Maven 3.10.0 is outside the documented supported range. And suggested to reach out to Azure DevOps/pipeline team to downgrade Apache Maven to version 3.9.x

https://docs.mulesoft.com/release-notes/mule-maven-plugin/mule-maven-plugin-4.10.2-release-notes#hardware-and-software-requirements

Azure DevOps

1 answer

Sort by: Most helpful
  1. SHOUMIK CHAKRAVARTY 1,150 Reputation points
    2026-10-11T02:19:35.99+00:00

    Hi @Sarkar, Sagar Mulesoft’s suggestion unfortunately won’t work here. You can’t request a Maven downgrade on Microsoft-hosted agents. From Microsoft-hosted agents: “You always have the latest version of the VM image you specify in your pipeline. Each time you run a pipeline, you get a fresh virtual machine for each job.” The toolchain comes with the image, it updates on Microsoft’s schedule, and there’s no way to pin Maven per customer.

    The supported way to control tool versions is to run the job inside a container. From Define container jobs: “For more control over task context, you can define and run pipeline jobs in containers to get the exact versions of operating systems, tools, and dependencies you want.”

    The link you shared shows the supported versions for Mule Maven Plugin 4.10.2: “Maven 3.9.0 to 3.9.15” and “Java 8, 11, 17, and 21”. Since you mentioned you’re on 4.6.0, double check its release notes, but the Maven ceiling is the same. Once Maven is pinned inside the container, the agent’s built-in version stops mattering.

    pool:
      vmImage: 'ubuntu-latest'
    
    container: maven:3.9.9-eclipse-temurin-17
    
    steps:
    - script: mvn -B clean package
    

    Match the JDK tag to whatever your build already uses. JDK 17 is on Mulesoft’s supported list. It’s a simple change you can test immediately, and it protects you from future image updates too, which matters because this will come up again.

    If you prefer full control over the machine, self-hosted agents or Managed DevOps Pools let you manage the whole toolchain yourself. For this issue though, the container route is the easiest fix.

    One more thing: I don't see any attached logs as mentioned on the comment. Attach it if you want someone to take a look, though none of the above depends on it.

    Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.