Your new Maven friend – the Mule Maven Plugin 2.0

September 28 2015


If you’re a Mule user, there’s a good chance that you’re using Maven to automate building and testing of your applications. We’re happy to announce Mule Maven Plugin 2.0, to help you automate your and . This plugin will help you no matter where do you want it to run: , a local Standalone server, , a local cluster or using the Mule Agent.

Continuous deployment and integration tests are a core part of software development best practices. And many of our customers are using Maven to help achieve those. The new version of our Maven plugins makes these pratices simple for Maven users. It can:

  1. Deploy and undeploy applications to different Mule environments
  2. It supports Mule Standalone, Mule Cluster, Anypoint Runtime Manager, CloudHub, and the Mule Agent
  3. It supports attaching to different lifecycle stages of Maven so you can use the plugin for both integration tests and continuous deployment.
  4. You can use the plugin with both Community and Enterprise Mule instances

Like Mule, it is licensed under Common Public Attribution License Version 1.0 and you can find the GitHub project here.

Getting Started

You can see several examples in the documentation, but here’s quick guide on how to get started. First, you need to add MuleSoft’s releases repository to your pom.xm or settings.xml so Maven can find the plugin:

Could not embed GitHub Gist 7f73fcc9338152b572f3: Bad credentials. The API can't be accessed using username/password authentication. Please create a personal access token to access this endpoint:

We recommend to use mule-app-maven-plugin for packaging your Mule application. This way, the mule--plugin will automatically pick the packaged Mule application and deploy it. Then, if you want to deploy the result of your build to CloudHub for example, add this to your Maven plugins section:

Could not embed GitHub Gist 454c91de720792553afa: Bad credentials. The API can't be accessed using username/password authentication. Please create a personal access token to access this endpoint:

A different use case is to run integration tests in a local Mule Standalone server, before deploying to qa or prod environments. Using both maven-failsafe-plugin and mule-maven-plugin gives you a simple and efficient way to do so:

Could not embed GitHub Gist 44f797cac05118b688b5: Bad credentials. The API can't be accessed using username/password authentication. Please create a personal access token to access this endpoint:

In this case the plugin will download the Mule distribution from a Maven repository (or use one that’s already installed), start the server during pre-integration-tests, and stop the server during post-integration-test phase. You only need to name your test so that it has the suffix “”.

These are just the basics, but you can also deploy domains, add third party libraries, deploy external applications, configure deployment arguments, and even run a custom Groovy script just before deploying. To get started, check out our documentation, read the release notes or try running one of the examples available in the documentation and make your build process a nice one.


We'd love to hear your opinion on this post

24 Responses to “Your new Maven friend – the Mule Maven Plugin 2.0”

  1. Is there a way to use the in the settings.xml? That’s the Maven way and there are reasons for that — such as not having credentials stored in source code and being able to change passwords without having to update every single project.

    Also: it would be good if you could elaborate how you see this work with multiple target environments (e.g. FAT/UAT/PROD).

    • Peter, at the time the plugin doesn’t support reading credentials from a Maven server, your two options are setting the credentials in a system property in your Maven command or to add a Maven property in your settings.xml.
      About deploying to multiple environments, you need one plugin execution for each environment, something like this:


      • Thanks for the information Ale.
        Can you please provide an example snippet of settings.xml for storing the cloud hub password? Keeping a plain password in source code is definitely not an option for me.

        Also is there a recommendation on encrypting this password.

  2. This is a nice plugin. One question I’ve about the plugin is about storing CloudHub’s plain password in POM.xml file. Is there a way to use encrypted password or not to store the password in the project’s POM.xml file? Thanks.

    • Richard, I’m glad that you like the plugin. You don’t need to store your CloudHub password, you can use ${password} in your config and when running maven do it like this: mvn clean deploy -Dpassword=myPass.

  3. I’ve been trying to use the maven mule plugin 2.0 to deploy to a specific sub-business group in cloudhub, but it is not behaving as expected.

    I have the following setup as far as environments and business groups go:

    Toplevel org
    Development env
    Development Business Group
    Development env
    Devtest env

    So I have 2 environments called Development. One under the top level organisation and one under the Development business group.

    I want to deploy using maven to the Development Env that is inside the Development business group, but everytime the application is deployed to the development environment that is directly under the toplevel organisation.

    Based on the information on , the relevant section of my pom is :






    if I change the Development tag to be Devtest (to deploy to a uniquely named environment) I get the error:

    [INFO] ————————————————————————
    [INFO] ————————————————————————
    [INFO] Total time: 8.457s
    [INFO] Finished at: Fri Oct 30 14:54:05 GMT 2015
    [INFO] Final Memory: 35M/542M
    [INFO] ————————————————————————
    [ERROR] Failed to execute goal
    (deploy) on project simple: Execution deploy of goal failed: Couldn’t find environment named [Devtest] -> [Help 1]

    So it basically looks like it is ignoring the tag or can’t see the environments that aren’t at the top level.

    I have tried specifying the toplevelorgNameDevelopment, but this also just deploys to the toplevel environment, not the sub-level one.

    I have tried changing the default envoronment for my user to be the sub-level development environment, but it still deploys to the toplevel environment.

    Am I missing something or is the businessgroup element not working correctly?

    Any advice gratefully received


    • Hello Alan, you are right about that and I apologize, business group support is available for version 2.1, which will be publicly available probably during the next week. Hope you can wait until then!

  4. I’m trying to run mvn clean deploy with the configurations show above, but I’m receiving this error:

    Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter

    Anyone experienced that too?

    • Skip maven-deploy-plugin execution adding this to your pom.xml:


    • Oh, I figured out.
      I have to add the code below to prevent the default deploy plugin to run:



  5. Hello,

    I’m trying to execute this plugin to deploy to Cloudhub from the command line in my Jenkins host, like this:

    mvn …

    But I’m receiving this error: Failed to execute goal (default-cli): Goal requires a project to execute but there is no POM in this directory

    Apparently this was possible in the old plugin:

    • Hello Vanessa,

      unfortunately we removed that behaviour since version 2.0, that was to make the configuration more simple and avoid complex setup and inconsistent configurations. We will try to think about that for the next release but I cannot promise anything. As an alternative you can use curl to hit CloudHub API to upload the application. Here you will find an example of the Groovy script that I use for the CloudHub tests. I’m also working on a ZSH plugin for Mule and I’m considering adding CloudHub capabilities. You are free to make pull requests if you want to collaborate. Or reply to this comment if you need help with CloudHub API.

      • Thanks, Ale,

        By now I changed to use the maven plugin.

      • I was configuring the Jenkins pipeline to continuous integration and deployment on Cloudhub of a Mule project.
        In the first job I build my Mule Maven project, generate the zip artifact and upload to a Artifactory repository, that keeps all my project releases.

        So, in the next jobs I need to deploy this artifact to the Cloudhub.
        Primarily I was definying this plugin in the pom.xml of the project, but in this case, in the second job (deploy job) I needed to compile the project again (because the plugin doesnt allow command line invokation).

        And this is a problem, because if in this moment the project wasn’t building, I couldn’t deploy my already generated artifact to Cloudhub, and it was a unnecessary time spent.
        So, instead of use the Cloudhub API and handle all the authentication and deployment requests by my own, I decided to keep this plugin that already manages all this and the trick was to create a separated pom.xml, a simple one that only defines this plugin and parameters. So I keep this pom in the Jenkins host and I can invoke the deploy to Cloudhub via command line using this pom.

        Below is the example that I can invoke like this:
        mvn clean deploy -Dcloudhub.mule.version=3.7.2 \
        -Dcloudhub.environment=DEVELOPMENT \
        -Dcloudhub.workers=1 -Dcloudhub.workers.size=Micro \
        -Dcloudhub.user=myusername -Dcloudhub.password=mypassword

        Cloudhub Deploy







        mulesoft release repository


  6. I am able to deploy to master branch. Under master(mymaster) we have dev, test and rel business groups. When I try to give businessGroup as mymaster\dev and given environment as Production( also tried for Development), it says environment Production not found(or Development not found).

  7. So upon review of the product it seems like the system hitched it self on “low-code” and “clicks instead of code”, yet the build process seems to be quite a bit up on code and is super tedious to figure out which plugins are needed to support the actual deployment, configuration and promotion / management.
    I’ve so far sorted we’ve got the mule-maven-plugin which seems to have changed xml markup a bit since the time this article was written, and now I’m seeing a mule-app-maven-plugin and a mule-deploy plugin. Is there a documented recommended end-to-end solution setting this up because I feel like I’m stuck in a loop of config hell. I actually walk way from this questioning if I should be telling the team to leverage Anypoint Studio and Platform vs this high-setup and code solution to Maven or Anypoint-CLI just to support a low-code app.