Sharing Custom Code
Besides all the common code that exists in a company, there are Mule specific programmatic artifacts that are worth considering sharing.
Let’s name a few:
Custom transformers - performing operations that none of the Mule stock transformers can perform (see here),
Custom components - typically Mule-aware or non-business oriented components, as business components are usually simple POJOs coming from pre-existing projects (see: here),
Custom expression evaluators - for the cases when a specific message extraction capacity is needed in several places of an application (see: here).
The most convenient way to share custom code across team is to rely on Maven’s dependency management mechanism. Here is an extract of a pom.xml referring to common code stored in a shared Maven library:
1 2 3 4 5 <dependency> <groupId>com.acme.mulings</groupId> <artifactId>common-mule-project</artifactId> <version>1.3</version> </dependency>
The Mule build plug-in will automatically bundle these extra dependencies in the /lib directory of the deployable application. In this case, the common-mule-project-1.3.jar will be added to this directory at build time, ready to be deployed and made available to the application running on Mule.