Reading Time: 4 minutes

3 defined a simple, universal structure for Mule ESB applications. It’s a simpler version of war file format, consisting of a zip file with three sorts of entries:

  • At the top level, configuration files and application properties files
  • In the lib directory, jar files
  • In the classes directory, classes and resource files

We also created a maven plugin to build apps. And we haven’t forgotten about the Ant fans in our community. There are two new Ant tasks to make creating and working with Mule applications a snap.

The first task packages up applications. For example:

latest report
Learn why we are the Leaders in management and iPaaS

This creates a mule application in the file named ${app.file}, using the configuration files in the directory src/main/app and the jar file ${app.jar} in the directory ${}. Note that the lib and config elements are standard Ant filesets, which give you a powerful syntax for selecting exactly the files you want.

The second task deploys applications to a Mule instance:

This installs two Mule applications in two different ways:

  • The order application is installed into the default Mule installation, which is the one pointed to by the Ant property ${dir.mule.home}.
  • The purchase application is specifically installed into the Mule installation at /usr/opt/mule.

The code for these tasks can be found on GitHub, here. You can download it and either use the already built mule-anttasks.jar, or build it yourself with (what else?) Ant. To use the new tasks in your Ant build scripts requires two steps:

  • To make the code available to Ant, add -lib mule-anttasks.jar to your Ant command line.
  • To make the tasks available within a build script,
    add the line as a child of the main <project> element.

To tie it all together, here’s a version of the Mule Echo example’s build.xml file that uses the new tasks:

Using these tasks, you can create and deploy Mule applications in Ant as simply and naturally as you’d create a jar or a war file.