Working with the Mule open source ESB project today, I was struck by the need to deploy project-specific jar files to Mule’s lib/user directory. This is fine if your Mule installation only needs to support a single instance of Mule, or multiple instances using the same jars.

Mulesource’s recommendation for supporting multiple instances is to run their bin/setup_local_instance script, which essentially copies the bin and conf directories to a new location, and then creates a new lib/user directory in that new location.

This certainly works, and is probably the best thing to do in a production envrionment. However, in a development environment, deploying your jar(s) to mule’s directory is an extra step. For instance, in this case, I was using Maven to build my Mule project. I like Maven quite a bit, and find it preferable to ANT, but, following it’s convention over configuration approach, it puts it’s packaged binary in your project’s target directory, and there’s no simple way to have it copied somewhere else. You can, of course, modify your POM, and do some fairly arcane stuff to get it copied, but ultimately, deployment to a server environment isn’t Maven’s thing.

Other solutions are possible, including sym-linking Maven’s target directory insto Mule’s lib/user directory, using an external deploy script, etc., etc. One thing that does not work is simply setting the classpath before invoking Mule, as the Mule startup script sets it’s own classpath.

It’s not well documented, nor recommended for production use, but it turns out that Mule supports a MULE_LIB environment variable, the contents of which get appended to Mule’s custom classpath, the same as if they were in lib/user.