Managing Dependencies and Plugins in Multi Module Project

Introduction

Here I will discuss how to manage dependencies and plugins in multi module project using maven. A multi-module project is built from a parent pom that manages a group of sub-modules. In most of the cases, the parent pom is located in the parent project’s root directory and must have packaging of type pom.

So in multi module project you need to put the required dependencies into the parent module’s pom file and child modules will inherit those dependencies from the parent pom.

Keeping all dependencies into one place, i.e., parent project’s pom makes your life easier for future maintenance, for example, if you need to change the version of a particular dependency then you just need to change in the parent project’s pom file and child pom file will automatically inherit the updated version.

There are two ways of managing dependencies and plugins in maven based multi-module project.

First Approach

Put all the dependencies under <dependencies/> tag in the parent pom file and all children modules will inherit the same dependencies. So you don’t need to redeclare dependencies in child pom.

Of course don’t forget to put versions for dependencies in parent pom file.

The advantage of using <dependencies> tag is that you don’t need to re-declare dependency in child pom file.

The disadvantage of using <dependencies> tag is all dependencies declared into parent pom will be inherited in all children pom files even if some child projects do not need all dependencies.

Similarly plugins can be managed using <plugins> tag. So all plugins declared in parent pom file will be inherited in the child pom file.

The advantage and disadvantage for <plugins> are similar as for <dependencies> tag.

For example, look at the below parent pom file. The child modules email-sevice and user-service will inherit all dependencies and plugins from this parent pom file.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.roytuts</groupId>
	<artifactId>maven-multi-module-project</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<packaging>pom</packaging>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<java.version>12</java.version>
	</properties>

	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.12</version>
			<scope>test</scope>
		</dependency>
	</dependencies>

	<build>
		<plugins>
			<plugin>
				<groupId>org.apache.maven.plugins</groupId>
				<artifactId>maven-compiler-plugin</artifactId>
				<version>3.8.1</version>
				<configuration>
					<source>${java.version}</source>
					<target>${java.version}</target>
				</configuration>
			</plugin>
		</plugins>
	</build>

	<modules>
		<module>email-service</module>
		<module>user-service</module>
	</modules>
</project>

If you want to override version or scope then you have to mention different version or scope in child pom file with the same dependency or plugin.

Related Posts:

Second Approach

Put all dependencies under <DependencyManagement/> tag in parent pom file with version for each dependency.

In this case you have to re-declare the dependency in child pom file. You don’t need to put the version for dependency in child pom. The version will be inherited from parent pom’s dependency.

If you want to override version for a particular dependency in child pom then only you have to put version for that particular dependency.

The advantage of using <DependencyManagement/> is all dependencies from parent pom will not be inherited into child pom until you re-declare into child pom.

The disadvantage of using <DependencyManagement/> is you have to re-declare the required dependency in child pom file.

Similarly plugins can be managed using <PluginManagement> tag. So all plugins declared in parent pom file will not be inherited in the child pom file until you re-declare in the child pom.

The advantage and disadvantage for <plugins> are same as for <dependencies> tag.

For example, look at the below parent pom file. In this case until you re-declare the same dependency or plugin into child pom file, the child module email-service or user-service will not inherit.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.roytuts</groupId>
	<artifactId>maven-multi-module-project</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<packaging>pom</packaging>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<java.version>12</java.version>
	</properties>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>junit</groupId>
				<artifactId>junit</artifactId>
				<version>4.12</version>
				<scope>test</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<build>
		<pluginManagement>
			<plugins>
				<plugin>
					<groupId>org.apache.maven.plugins</groupId>
					<artifactId>maven-compiler-plugin</artifactId>
					<version>3.8.1</version>
					<configuration>
						<source>${java.version}</source>
						<target>${java.version}</target>
					</configuration>
				</plugin>
			</plugins>
		</pluginManagement>
	</build>

	<modules>
		<module>email-service</module>
		<module>user-service</module>
	</modules>
</project>

If you want to override version or scope then you have to mention different version or scope in child pom file with the same dependency or plugin.

Remember you don’t need to put <DependencyManagement/> or <PluginManagement> tag in child pom.

Hope you got an idea how to manage dependencies in parent and child pom files in multi-module projects.

Thanks for reading.

Leave a Reply

Your email address will not be published. Required fields are marked *