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.
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.
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:
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:
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’.