Did you ever want to make one of the Mule message processors read some of the properties that you had in the POM file? Probably yes but you didn’t know that it can be done using the Maven Resources plugin. You can pass properties as VM arguments but reading them from the POM is even more interesting and sometimes really handy.
Sit down, grab your coffee and let’s dig into the topic!
What is its purpose?
Imagine having some properties in the POM file that you need in the actual code of the API. For example, the version might be something that is set by your fancy pipeline. If you created such automation you probably don’t want code redundancy and neither changing manually the version in your properties files since you will need that information when the application is producing logs and you will probably forget to update it.
I am now convinced but how can I achieve this?
Well, let’s say this is how your POM file looks like in the first section:
The value in the “version” tags is what we are looking for. Having the application name in the logs would be useful as well, right? Let’s include it as well in our use case then.
Let’s create the properties file and include the two fields that will be populated by the values in the POM file.
Dollar sign with square brackets. That’s something we are used to! Nothing complicated until now.
Does it look too easy? Yes, because this is not enough.
From a project lifecycle perspective, the properties in the POM exist only during the Maven execution. That includes the moment when the project is built but as soon as this part is completed all the properties are lost and won’t become readable by the Mule application.
This is where the Maven Resources plugin comes in help
In order to populate the property file at project build time (this is the moment when Maven does its job) we need to use the Maven Resources plugin’s resource filtering capabilities. This plugin is enabled by default in Mule Applications and what it will do is replacing all the resources' placeholders with the actual data, not by modifying the property file itself but by the file that is copied to the output target directory.
The resources are divided into two groups: main resources and test resources. The main resources are associated with the main source code and the test resources are associated with the unit tests.
But what if there are placeholders in other files that we don’t want to modify?
Let’s limit the files that the Maven Resources plugin will look at by adding the code snippet below in the <build> session of the POM file.
By adding this part we are telling the Maven Resources plugin to not modify the files in the “src/main/resources” folder. Note that the first “filtering” is set to “false”.
Then we define the same folder with the filtering set to “true” and we specify which files should be taken in account when replacing the placeholders. In the example will be all files inside the “properties” folder that follow the *.yaml pattern.
You can also specify multiple files to which you would like to apply the resources filtering. Just add multiple “include” tags and put all the files you need.
In the picture below you can see the files organization of the use case example project
Congratulations, you are now able to use the placeholder in your Mule configurations by referring your property file which in turn will be referring the properties in the POM file!
In the screenshot below you will find a section of the log message where the two properties are being read by the Mule application. As you can see the values are successfully resolved with the correct properties in the POM. Mission successful!
If you want to learn more about the Maven Resources Plugin and resources filtering please check the official documentation here: