Over a million developers have joined DZone.

Building Enterprise Mule Apps with Gradle – Part 3

DZone's Guide to

Building Enterprise Mule Apps with Gradle – Part 3

· Integration Zone ·
Free Resource

WSO2 is the only open source vendor to be named a leader in The Forrester Wave™: API Management Solutions, Q4 2018 Report. Download the report now or try out our product for free.

[This article was originally written by Juan Cavalloti.]

This is the third post on the Gradle Plugin Series, and a lot has happened to the plugin since the first article of the series was published. Today, I’m announcing exciting new features useful for tackling enterprise users’ needs. For more information on how to get started on building apps with gradle, please check the previous blog post and specially the project’s readme file. Now let’s get started.

Fine tuning Mule Dependencies

This plugin is designed to be future-proof and still remain concise, so we’ve introduced a DSL for customizing the mule dependencies to be included as part of the build. This allows users to (in a very concise way) fine-tune the modules, transports and connectors included when unit-testing, compiling your code and running your app.

mule.components {

    //exclude jdbc transport, deprecated in 3.5.0
    transports -= 'jdbc'

    //include DB module.
    modules += 'db'

    //add a cloud connector
    connector name: 'mule-module-cors', version: '1.1'

    //add an external module
    module name: 'mule-module-apikit-plugin', version: '1.3', noClassifier: true

Also, this DSL enables inclusion of Devkit-generated modules as zip plugins, improving the classloading isolation and allowing you to separate the libraries you define as dependencies from the transitive dependencies included in the plugins; at the same time reducing the amount of files retrieved from the remote server.

Shared Resources (aka Domains)

Mule 3.5.0, introduced the ability to share resources, connectors and libraries between mule projects. It also introduced a new project structure and deployment procedure. The gradle plugin supports this entirely and even allows you to create a template domain project so you can quickly learn what the new structure looks like.

In order to leverage domain projects, the plugin takes advantage of gradle’s ability to build multi-module projects. This way, all the semantics are kept while enabling features such as a single build.gradle file and also compatibility with IDE’s that support gradle.

You simply need to define a standard build.gradle that applies the ‘mule-domain’ plugin and a standard ‘settings.gradle’ to define the project’s modules.

buildscript {
	dependencies {
		classpath group: 'org.mulesoft.build', name: 'mule-gradle-plugin', version: '1.0.0-SNAPSHOT'

	repositories {

apply plugin: 'mule-domain'

mule.version = '3.5.0'
include 'api', 'backend'

The domain plugins have several goodies including the ability to check if the modules are correctly configured for the domain, fixing the configuration to make sure it works and installing the resulting zip file into a given mule server.

Upload your apps to the Mule Management Console

This feature is, at the moment of writing this post, exclusively available only to ones who choose to build with gradle. The mule gradle plugin offers a very simple DSL for defining your environments, and uploading artifacts into the Management console of the given environment, this feature is similar to the one offered by Anypoint Studio but available for your automated builds. The following is an example of what this DSL looks like:

//...standard definition

apply plugin: 'mmc'

//...standard definition

mmc.environments {
    //different environments could be managed by different consoles
    dev url: 'http://managmentConsole:8080/mmc', appName:'myApp', version:'1.0.2'
    //two different environments managed by the same console
    prod url: 'http://prodEnv:8080/mmc', appName:'prodApp', username: 'admin', password: 'test'
    'pre-prod' url: 'http://prodEnv:8080/mmc', appName: 'preProdApp', username: 'admin', password: 'test'

    defaultEnvironment = 'prod'

With this definition in place, we may simply use the ‘uploadToRepository’ task and the app will be built, tested, packaged and uploaded to MMC’s repository.

Deploy your apps to CloudHub!

This feature is also, at the moment of writing this post, available only for users building their apps with gradle. This plugin now offers the ability to deploy your app to a given CloudHub domain, and through a simple DSL, define multiple environments where the app could be deployed. The following is an example on how to define and use the CloudHub plugin:

//standard plugin definition
apply plugin: 'cloudhub'

//standard plugin configuration

cloudhub.domains {
    myapp  username: 'login-username', password: 'pass'
    'myapp-dev' username: 'dev-username', password: 'pass'

    defaultDomain = 'myapp-dev'

With this definition in place, we may simply invoke the ‘deploy’ task and the app will be built, tested, packaged and uploaded into the configured CloudHub domain.

Unit test apps with DataMapper

Automating unit tests with maven and DataMapper isn’t really a piece of cake. There are several configurations to be created and tested. This is simply because the DataMapper runtime needs to be present (in a non-standard way) when running the unit tests. With this pain in mind, the gradle plugin leverages the tasks required to properly set the testing environment for running DataMapper tests with no additional configuration! The only thing required is to have a valid mule license with DataMapper entitlements in ‘src/test/resources’.

Read the WSO2 Methodology for Agility to see how you can transform your integration projects from semi-agile to a scalable continuous agile approach.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}