Grouping Maven Dependencies

Maven can be used to manage everything from simple, single-project systems to builds that involve hundreds of inter-related submodules. Part of the learning process with Maven isn’t just figuring out the syntax for configuring Maven, it is learning the “Maven Way”—the current set of best practices for organizing and building projects using Maven. This is the first in a series of posts that will attempt to distill some of this knowledge to help you adopt best practices from the start without having to wade through years of discussions on the Maven mailing lists.

Grouping Dependencies

If you have a set of dependencies which are logically grouped together. You can create a project with pom packaging that groups dependencies together. For example, let’s assume that your application uses Hibernate, a popular Object-Relational mapping framework. Every project which uses Hibernate might also have a dependency on the Spring Framework and a MySQL JDBC driver. Instead of having to include these dependencies in every project that uses Hibernate, Spring, and MySQL you could create a special POM that does nothing more than declare a set of common dependencies. You could create a project called persistence-deps (short for Persistence Dependencies), and have every project that needs to do persistence depend on this convenience project:
<project> <groupid>mx.com.mycompany</groupid> <artifactid>persistence-deps</artifactid> <version>1.0</version> <packaging>pom</packaging> <dependencies> <dependency> <groupid>org.hibernate</groupid> <artifactid>hibernate</artifactid> <version>${hibernateVersion}</version> </dependency> <dependency> <groupid>org.hibernate</groupid> <artifactid>hibernate-annotations</artifactid> <version>${hibernateAnnotationsVersion}</version> </dependency> <dependency> <groupid>org.springframework</groupid> <artifactid>spring-hibernate3</artifactid> <version>${springVersion}</version> </dependency> <dependency> <groupid>mysql</groupid> <artifactid>mysql-connector-java</artifactid> <version>${mysqlVersion}</version> </dependency> </dependencies> <properties> <mysqlversion>(5.1,)</mysqlversion> <springversion>(2.0.6,)</springversion> <hibernateversion>3.2.5.ga</hibernateversion> <hibernateannotationsversion>3.3.0.ga</hibernateannotationsversion> </properties> </project>
If you create this project in a directory named persistence-deps, all you need to do is create this pom.xml and run mvn install. Since the packaging type is pom, this POM is installed in your local repository. You can now add this project as a dependency and all of its dependencies will be added to your project. When you declare a dependency on this persistence-deps project, don’t forget to specify the dependency type as pom.
<project> <description>This is a project requiring JDBC</description> ... <dependencies> ... <dependency> <groupid>mx.com.mycompany</groupid> <artifactid>persistence-deps</artifactid> <version>1.0</version> <type>pom</type> </dependency> </dependencies> </project>
If you later decide to switch to a different JDBC driver (for example, JTDS), just replace the dependencies in the persistence-deps project to use net.sourceforge.jtds:jtds instead of mysql:mysql-java-connector and update the version number. All projects depending on persistence-deps will use JTDS if they decide to update to the newer version. Consolidating related dependencies is a good way to cut down on the length of pom.xml files that start having to depend on a large number of dependencies. If you need to share a large number of dependencies between projects, you could also just establish parent-child relationships between projects and refactor all common dependencies to the parent project, but the disadvantage of the parent-child approach is that a project can have only one parent. Sometimes it makes more sense to group similar dependencies together and reference a pom dependency. This way, your project can reference as many of these consolidated dependency POMs as it needs.

Maven uses the depth of a dependency in the tree when resolving conflicts using a nearest-wins approach. Using the dependency grouping technique above pushes those dependencies one level down in the tree. Keep this in mind when choosing between grouping in a pom or using dependencyManagement in a parent POM