Dependency Management in Maven done right +

Despair, anger, perplexity, pain – I think we all know this moments when dealing with large Maven projects. I have seen a lot of posts in the lasts months who use some of this words. After years with Maven we learned how to deal with it. Not the pain, I mean to deal with Maven. I want to share a way to avoid some pitfalls or give you some advices if you are in trouble.

Maven is a good tool to handle your dependencies. You shouldn’t copy the necessary artifacts by hand in your lib folder. It is the beginning of the end for your project. Transitive dependencies could ease the management of your dependencies and Maven is the right tool for this. But sometimes it is to much magic behind the scenes. There could be a lot of transitive dependencies and there could be conflicts. Even more if your projects gets larger and uses more and more open source frameworks. We had problems with two actions:

• Change the version of a dependency
• Update the version of Maven

Change the version of a dependency

If you update the version of a dependency this could cause completely different transitive dependencies to be fetched. Normally no big deal, but you need to clean your artifacts. Often you just use mvn install to install your artifact. But without the clean target, the old dependencies are still in your target folder. Remember to use mvn clean install when changing the version of a dependency. But there is also another place, where old dependencies can survive. If you hot deploy your artifacts to your server, you should also delete the old artifacts and extracted folders. After that you are in a really clean condition.

Update the version of Maven

We had problems with transitive dependencies when changing the version of Maven. Make sure that every team member and build server uses the same version. Then you can still have problems, but there are no different transitive resolutions on different computers. Can be very confusing if one person in the team has version A and another one has version B. I think the Maven team tries to reduce this, but if there are changes in the dependency resolution, it could happen that conflicts are solved in a different way.

What about real trouble?

If you have a lot open source dependencies, there are much more transitive dependencies. Maven tries to resolve conflicts, but you will often find a situation, where dependencies A and B needs the same transitive dependency but in a different version. This can produce situations, described in the post: Maven supports JAR hell. Something is wrong and you have a lot of unwanted dependencies in your library folder. The next step is to find out, where they come from. This can be complicated, because transitive dependencies also have own transitive dependencies.

Find out where the dependencies come from

There are different solutions for this and Maven has improved the detection of dependencies for users. Most of the time I use the Maven site. It is always a good idea to use this feature, because it can give you a nice overview of your project. Take the time and configure your site, it is very helpful for the team.

To generate the Maven site just use: mvn site

This will generate a linked web site, where you can use a lot plugins. There is also the section dependencies, where you can have a look what dependencies exist and watch the transitive dependencies tree.

But there are also command line options. First of all the Maven Dependency Plugin. To get the transitive dependencies tree just type: mvn dependency:tree

It will display where the dependencies come from. It is also possible to filter the output or find conflicts.

We also use the concept of parent POMs with a deeper hierarchy. Sometimes you need to know, how your effective POM in the sub-project looks like. To get this information use: mvn help:effective-pom

You should have a look at the Maven Help Plugin, because there are some interesting other options.

Start your own dependency management

That doesn’t mean that you don’t use Maven. But most of the time you know your artifacts and their actual version. And you want a specific version to be included. You also want to have a consistent version of an artifact used through all sub-projects, then you can use declarative dependency management in Maven. That can avoid classpath issues. It is also very easy to upgrade a version, because the child-POMs don’t have a version included. They use the version defined in the parent POM.

We manage our dependencies in our master parent POM. There is a section in the XML called dependencyManagement. There you can list your dependencies and add the group, the artifactId and very important: the version. Now every time Maven tries to resolve a dependency it is using this specified version. Easy, isn’t it? Yes, the dependency management list is getting larger, but in a large project you are very pleased to find always the correct version of your dependencies.

Read more about this in the Maven documentation.

For us it was a great time saver, because we had less problems with Maven. You don’t need your own dependency management, but if you run in trouble think about using it.

If you want the know about the best Maven plugins, check out the Top 10 Maven plugins on our blog.