One of the major changes in Mule 4 was introducing components modularization. Although it is a big step forward it has some drawback that you should be aware of. In this article, we will look at keeping our mule application up to date. Especially now as MuleSoft is rapidly developing their new product.

Mule 4 modularization

In this paragraph, I will briefly introduce what I mean by mule 4 modularization. Previously you had a bundle of libraries. As a result less to manage. On the other hand, it made the update of one particular library hard as the whole bundle would need to be updated. Not just the single one library. Thus, MuleSoft has decided to split major modules out of the bundle. I have mentioned that in Mule 4 revealed and using domain project articles.

In the diagram below you can see sample Mule application and its dependencies. It depends on HTTP, Munit, FTP and Spring modules. Each has its own version. Imagine now, that MuleSoft has prepared new critical fix in HTTP Module. You can update only this module version in your pom file.

Mule application with dependencies to modules such as HTTP, Munit, FTP and Spring
Mule application with dependencies

Moreover, your packaged application weights more as it has extra dependencies that were earlier embeded into the runtime.

Keep it up to date

Okay, instead of one dependency I have now more. As a consequence, there is more to manage. Yet, I do not need to update dependencies at all if everything is working as expected. What if there is an error or MuleSoft has published a new version with some major bugfixes?

In Anypoint Studio you are not notified at all when there is a new version of one of the modules. You need to do it manually. But can be problematic to get the new version number.

Updating dependency can help

Lately, I had a problem with my MUnits. There was a problem with loading ObjectStore bean into memory. It was frustrating. However, I thought that maybe this bug has been fixed already. So I decided to update the version of MUnit Module dependency. Hopefully, it helped. However, it was not an easy task to find the version number.

Maven plugin to the rescue

In order to see which dependency is outdated, you can call a simple maven command, such as:

mvn versions:display-dependency-updates

Below you can see sample output of such command on one of my mule projects. As you can see I had a lot of dependencies outdated. It may make sense to update them all. However, I have not decided to get BETA version of the MUnit library.

 [INFO] The following dependencies in Dependencies have newer versions:
 [INFO]   com.ibm.icu:icu4j ………………………………… 60.2 -> 63.1
 [INFO]   com.mulesoft.munit:munit-runner ……………… 2.1.4 -> 2.2.0-BETA
 [INFO]   com.mulesoft.munit:munit-tools ………………. 2.1.4 -> 2.2.0-BETA
 [INFO]   org.mule.connectors:mule-db-connector …………….. 1.3.4 -> 1.5.0
 [INFO]   org.mule.connectors:mule-http-connector …………… 1.3.1 -> 1.5.0
 [INFO]   org.mule.connectors:mule-objectstore-connector …….. 1.1.2 -> 1.1.3
 [INFO]   org.mule.modules:mule-scripting-module ……………. 1.1.1 -> 1.1.4
 [INFO]   org.mule.modules:mule-validation-module …………… 1.2.2 -> 1.4.0
 [INFO]
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
 [INFO] ------------------------------------------------------------------------
 [INFO] Total time:  31.874 s
 [INFO] Finished at: 2019-02-14T13:03:42+01:00
 [INFO] ------------------------------------------------------------------------

Summary

In short, modularization makes our application dependencies more clear. We know what is used there for sure. However we need to manage more dependencies, but that is not as hard as it may seem. We may use Maven version command to get information what is up to date and what we should update within the pom file.

Keep your mule’s dependency up to date
Tagged on:         

Leave a Reply

Your e-mail address will not be published. Required fields are marked *