Maven Tools & Archetypes

motif

For a while now there have been for creating mule apps and domains. Such make getting started with development easier by automatically generating the basic core structure and files of mule projects (think configuration files, test classes, pom). This is especially interesting since the introduction in 3.5.0 of shared resources through mule domains which could make your app depend on another external project (a domain) and using Maven to manage dependencies makes perfect sense. We will see how to use these archetypes to create a domain and  an application that uses it.

IMPORTANT: This post is intended for developers comfortable and familiar with Maven.

Creating a domain

We’ll start by creating a domain where we’ll define an HTTP listener to be shared.

mvn archetype:generate -DarchetypeGroupId=org.mule.tools.maven -DarchetypeArtifactId=maven-archetype-mule-domain -DarchetypeVersion=1.1 -DgroupId=org.myfakecompany.domain -DartifactId=my-mule-domain -Dversion=1.0-SNAPSHOT -Dpackage=org.myfakecompany.domain

This will create a project named my-mule-domain that contains a mule-domain-config.xml file where we can define our listener config:

Creating an app

Now we’ll create a project for an app that uses my-mule-domain. In this case, we can indicate which transports and modules we’ll be starting with and the mule version we’ll be using.

mvn archetype:generate -DarchetypeGroupId=org.mule.tools.maven -DarchetypeArtifactId=maven-archetype-mule-app -DarchetypeVersion=1.1 -DgroupId=org.myfakecompany.app -DartifactId=my-mule-app -Dversion=1.0-SNAPSHOT -DmuleVersion=3.7.0 -Dpackage=org.myfakecompany.app -Dtransports=http,vm -Dmodules=db,xml,ws -DdomainGroupId=org.myfakecompany.domain -DdomainArtifactId=my-mule-domain -DdomainVersion=1.0-SNAPSHOT

This will create a project named my-mule-app that contains a mule app configuration file already set up with the namespaces of the transports and modules indicated, as well as the dependencies for them set up in the project’s pom file. In there you’ll also find a mule-deploy.properties file with the domain specified to my-mule-domain and an ExampleFunctionalTestCase for our app.

Let’s modify the app to use the shared HTTP listener and it’s test accordingly. We’ll get rid of the vm endpoints and extra initial message processors and add our listener: 

In ExampleFunctionalTestCase we can now use the MuleClient to send a request to “http://localhost:8081/domain/test”. Let’s replace the vm related client code and modify the expected payload since now we’ll be expecting “Received”:

That’s it, we now have an application that’s using a listener defined in a domain AND a test case for it. This works because the external domain project is added as a dependency of our project, as well as a Maven plugin to unpack it’s configuration file, all of which was set up when we created the app through the archetype. Just compile everything and run the test. 

You can find the entire code for the domain and app here.

Extra

Archetypes are not all there is to offer for Maven projects though. Each of the projects mentioned above uses a special maven plugin to manage the packaging into deployable .zip files. 

If I want to generate the deployable .zip for my domain I just have to run:

mvn package

To handle deployment, you can use the Mule Maven Plugin which supports deploying to a standalone instance, a cluster, Anypoint Runtime Manager or CloudHub. You can find some examples here.

To learn more on our Maven Tools you can visit our github project and check out our docs site for this and even more information about developing applications with Maven.


We'd love to hear your opinion on this post


3 Responses to “Maven Tools & Archetypes”

  1. Nice abstraction using maven

  2. I think your domain pom should have reference to dependent apps instaed of the other way around.

    • Hi! And sorry for the super late response.
      If the domain pom were to reference the apps, you would have to edit the domain project each time another app was added. I do think keeping track of the apps using your domain is useful, but in that scenario you should use a domain bundle project. There you can define the domain project and an apps project that includes every app. You can find more on this here regarding how to “Create a Complete Mule Domain Project”.
      Thanks!