Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Building Mule apps with Gradle and Mule Studio

DZone's Guide to

Building Mule apps with Gradle and Mule Studio

· Integration Zone
Free Resource

Modernize your application architectures with microservices and APIs with best practices from this free virtual summit series. Brought to you in partnership with CA Technologies.

[This article was originally written by Juan Cavallotti.]

Recently, I discussed how to build mule integrations using Gradle. This is a follow up post to discuss how to work with this plugin and mule studio, and to discuss some relevant enterprise features. This post assumes you already know how to do the basic setup of the gradle plugin (discussed on my previous post), so if you have not done it before, please go ahead and read it before continuing.

gradle and mule

Creating a Mule Studio Project

From your gradle project, you can easily change it to a Mule Studio type just by applying the ‘mulestudio’ plugin and selecting the appropriate mule version, here is an example:

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

	repositories {
		mavenLocal()
	}
}

apply plugin: 'mulestudio'

mule.version = '3.4.2'

Now you can simply run ‘gradle studio’ from the command line and it will create the necessary files so you can import the project into your workspace.

Importing it into Studio

In order to import your newly created project into Mule Studio, you can proceed in the following way:

Right click on your project and select ‘Import’

Pick ‘Existing projects into workspace’ and click on ‘Next’. Navigate to your project’s path and select it, to confirm, Studio should display it in the ‘projects’ panel. After this just click on finish.

The resulting project should be no different than a project created from Mule Studio, now we can focus on discussing how the build path will be configured.

Digging into the build path

The gradle plugin will include in your project’s build path all the non-provided dependencies that you have declared as well as the configured runtime (specified in mule-project.xml) and the JVM configured in your build. I decided to exclude all provided dependencies to maintain the same semantics as the non-studio build, we suppose that provided dependencies are part of the container and since mule studio already provides a build path for a container it would be up to the user to install the jars there, the same case as if the app was to be deployed on a standalone container. This design decision can be worked-around easily from your build if required by taking advantage of normal gradle features.

Enterprise Users, you’re not Forsaken!

The latest version of the plugin has incorporated a flag to switch from community version to enterprise (by default turned on) and take advantage of the enterprise artifacts. These artifacts are hosted on our exclusive nexus repository and the plugin allows you to simply enter your repository credentials and get the artifacts online from this repository, here is an example on how your build script would look with credentials:

buildscript {
	dependencies {
		classpath group: 'org.mulesoft.build', name: 'mule-gradle-plugin', version: '1.0.0-SNAPSHOT'
	}
 
	repositories {
		mavenLocal()
	}
}
 
apply plugin: 'mulestudio'
 
mule.version = '3.4.2'

//specify the enterprise repo credentials.
mule.enterpriseRepoUsername = 'your-username'
mule.enterpriseRepoPassword = 'your-password'

Final words

Last but not least, since the writing of my previous post I’ve seen great community interest around this plugin. I’d like to thank those users who have contributed to the project either by submitting bug reports as well as pull requests, your contribution is greatly appreciated, thank you very much!

The Integration Zone is proudly sponsored by CA Technologies. Learn from expert microservices and API presentations at the Modernizing Application Architectures Virtual Summit Series.

Topics:

Published at DZone with permission of Ross Mason, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}