Mule 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 Mule 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 Mule applications. For example:
latest report
Learn why we are the Leaders in API 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 ${dir.build}. 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.
