1. Introduction
Building a software project typically consists of such tasks as downloading dependencies, putting additional jars on a classpath, compiling source code into binary code, running tests, packaging compiled code into deployable artifacts such as JAR, WAR, and ZIP files, and deploying these artifacts to an application server or repository.
Apache Maven automates these tasks, minimizing the risk of humans making errors while building the software manually and separating the work of compiling and packaging our code from that of code construction.
In this tutorial, we’re going to explore this powerful tool for describing, building, and managing Java software projects using a central piece of information — the Project Object Model (POM) — that is written in XML.
2. Why Use Maven?
The key features of Maven are:
- simple project setup that follows best practices: Maven tries to avoid as much configuration as possible, by supplying project templates (named archetypes)
- dependency management: it includes automatic updating, downloading and validating the compatibility, as well as reporting the dependency closures (known also as transitive dependencies)
- isolation between project dependencies and plugins: with Maven, project dependencies are retrieved from the dependency repositories while any plugin’s dependencies are retrieved from the plugin repositories, resulting in fewer conflicts when plugins start to download additional dependencies
- central repository system: project dependencies can be loaded from the local file system or public repositories, such as Maven Central
3. Project Object Model
The configuration of a Maven project is done via a Project Object Model (POM), represented by a pom.xml file. The POM describes the project, manages dependencies, and configures plugins for building the software.
The POM also defines the relationships among modules of multi-module projects. Let’s look at the basic structure of a typical POM file:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.baeldung</groupId>
<artifactId>org.baeldung</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>org.baeldung</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
//...
</plugin>
</plugins>
</build>
</project>
Let’s take a closer look at these constructs.
3.1. Project Identifiers
Maven uses a set of identifiers, also called coordinates, to uniquely identify a project and specify how the project artifact should be packaged:
- groupId – a unique base name of the company or group that created the project
- artifactId – a unique name of the project
- version – a version of the project
- packaging – a packaging method (e.g. WAR/JAR/ZIP)
The first three of these (groupId:artifactId:version) combine to form the unique identifier and are the mechanism by which you specify which versions of external libraries (e.g. JARs) your project will use.
3.2. Dependencies
These external libraries that a project uses are called dependencies. The dependency management feature in Maven ensures automatic download of those libraries from a central repository, so you don’t have to store them locally.
This is a key feature of Maven and provides the following benefits:
- uses less storage by significantly reducing the number of downloads off remote repositories
- makes checking out a project quicker
- provides an effective platform for exchanging binary artifacts within your organization and beyond without the need for building artifact from source every time
In order to declare a dependency on an external library, you need to provide the groupId, artifactId, and the version of the library. Let’s take a look at an example:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.3.5.RELEASE</version>
</dependency>
As Maven processes the dependencies, it will download Spring Core library into your local Maven repository.
3.3. Repositories
A repository in Maven is used to hold build artifacts and dependencies of varying types. The default local repository is located in the .m2/repository folder under the home directory of the user.
If an artifact or a plug-in is available in the local repository, Maven uses it. Otherwise, it is downloaded from a central repository and stored in the local repository. The default central repository is Maven Central.
Some libraries, such as JBoss server, are not available at the central repository but are available at an alternate repository. For those libraries, you need to provide the URL to the alternate repository inside pom.xml file:
<repositories>
<repository>
<id>JBoss repository</id>
<url>http://repository.jboss.org/nexus/content/groups/public/</url>
</repository>
</repositories>
Please note that you can use multiple repositories in your projects.
3.4. Properties
Custom properties can help to make your pom.xml file easier to read and maintain. In the classic use case, you would use custom properties to define versions for your project’s dependencies.
Maven properties are value-placeholders and are accessible anywhere within a pom.xml by using the notation ${name}, where name is the property.
Let’s see an example:
<properties>
<spring.version>4.3.5.RELEASE</spring.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${spring.version}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>${spring.version}</version>
</dependency>
</dependencies>
Now if you want to upgrade Spring to a newer version, you only have to change the value inside the<spring.version> property tag and all the dependencies using that property in their <version> tags will be updated.
Properties are also often used to define build path variables:
<properties>
<project.build.folder>${project.build.directory}/tmp/</project.build.folder>
</properties>
<plugin>
//...
<outputDirectory>${project.resources.build.folder}</outputDirectory>
//...
</plugin>
3.5. Build
The build section is also a very important section of the Maven POM. It provides information about the default Maven goal, the directory for the compiled project, and the final name of the application. The default build section looks like this:
<build>
<defaultGoal>install</defaultGoal>
<directory>${basedir}/target</directory>
<finalName>${artifactId}-${version}</finalName>
<filters>
<filter>filters/filter1.properties</filter>
</filters>
//...
</build>
The default output folder for compiled artifacts is named target, and the final name of the packaged artifact consists of the artifactId and version, but you can change it at any time.
3.6. Using Profiles
Another important feature of Maven is its support for profiles. A profile is basically a set of configuration values. By using profiles, you can customize the build for different environments such as Production/Test/Development:
<profiles>
<profile>
<id>production</id>
<build>
<plugins>
<plugin>
//...
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>development</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<build>
<plugins>
<plugin>
//...
</plugin>
</plugins>
</build>
</profile>
</profiles>
As you can see in the example above, the default profile is set to development. If you want to run the production profile, you can use the following Maven command:
mvn clean install -Pproduction
4. Maven Build Lifecycles
Every Maven build follows a specified lifecycle. You can execute several build lifecycle goals, including the ones to compile the project’s code, create a package, and install the archive file in the local Maven dependency repository.
4.1. Lifecycle Phases
The following list shows the most important Maven lifecycle phases:
- validate – checks the correctness of the project
- compile – compiles the provided source code into binary artifacts
- test – executes unit tests
- package – packages compiled code into an archive file
- integration-test – executes additional tests, which require the packaging
- verify – checks if the package is valid
- install – installs the package file into the local Maven repository
- deploy – deploys the package file to a remote server or repository
4.2. Plugins and Goals
A Maven plugin is a collection of one or more goals. Goals are executed in phases, which helps to determine the order in which the goals are executed.
The rich list of plugins that are officially supported by Maven is available here. There is also an interesting article how to build an executable JAR on Baeldung using various plugins.
To gain a better understanding of which goals are run in which phases by default, take a look at the default Maven lifecycle bindings.
To go through any one of the above phases, we just have to call one command:
mvn <phase>
For example, mvn clean install will remove the previously created jar/war/zip files and compiled classes (clean) and execute all the phases necessary to install new archive (install).
Please note that goals provided by plugins can be associated with different phases of the lifecycle.
5. Your First Maven Project
In this section, we will use the command line functionality of Maven to create a Java project.
5.1. Generating a Simple Java Project
In order to build a simple Java project, let’s run the following command:
mvn archetype:generate -DgroupId=org.baeldung -DartifactId=org.baeldung.java -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
The groupId is a parameter indicating the group or individual that created a project, which is often a reversed company domain name. The artifactId is the base package name used in the project, and we use the standard archetype.
Since we didn’t specify the version and the packaging type, these will be set to default values — the version will be set to 1.0-SNAPSHOT, and the packaging will be set to jar.
If you don’t know which parameters to provide, you can always specify interactiveMode=true, so that Maven asks for all the required parameters.
After the command completes, we have a Java project containing an App.java class, which is just a simple “Hello World” program, in the src/main/java folder.
We also have an example test class in src/test/java. The pom.xml of this project will look similar to this:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.baeldung</groupId>
<artifactId>org.baeldung.java</artifactId>
<packaging>jar</packaging>
<version>1.0-SNAPSHOT</version>
<name>org.baeldung.java</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.1.2</version>
<scope>test</scope>
</dependency>
</dependencies>
</project>
As you can see, the junit dependency is provided by default.
5.2. Compiling and Packaging a Project
The next step is to compile the project:
mvn compile
Maven will run through all lifecycle phases needed by the compile phase to build the project’s sources. If you want to run only the test phase, you can use:
mvn test
Now let’s invoke the package phase, which will produce the compiled archive jar file:
mvn package
5.3. Executing an Application
Finally, we are going to execute our Java project with the exec-maven-plugin. Let’s configure the necessary plugins in the pom.xml:
<build>
<sourceDirectory>src</sourceDirectory>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.6.1</version>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.5.0</version>
<configuration>
<mainClass>org.baeldung.java.App</mainClass>
</configuration>
</plugin>
</plugins>
</build>
The first plugin, maven-compiler-plugin, is responsible for compiling the source code using Java version 1.8. The exec-maven-plugin searches for the mainClass in our project.
To execute the application, we run the following command:
mvn exec:java
6. Multi-Module Projects
The mechanism in Maven that handles multi-module projects (also called aggregator projects) is called Reactor.
The Reactor collects all available modules to build, then sorts projects into the correct build order, and finally, builds them one by one.
Let’s see how to create a multi-module parent project.
6.1. Create Parent Project
First of all, we need to create a parent project. In order to create a new project with the name parent-project, we use the following command:
mvn archetype:create -DgroupId=org.baeldung -DartifactId=parent-project
Next, we update the packaging type inside the pom.xml file to indicate that this is a parent module:
<packaging>pom</packaging>
6.2. Create Submodule Projects
In the next step, we create submodule projects from the directory of parent-project:
cd parent-project mvn archetype:generate -DgroupId=org.baeldung -DartifactId=core mvn archetype:generate -DgroupId=org.baeldung -DartifactId=service mvn archetype:generate -DgroupId=org.baeldung -DartifactId=webapp
To verify if we created the submodules correctly, we look in the parent-project pom.xml file, where we should see three modules:
<modules>
<module>core</module>
<module>service</module>
<module>webapp</module>
</modules>
Moreover, a parent section will be added in each submodule’s pom.xml:
<parent>
<groupId>org.baeldung</groupId>
<artifactId>parent-project</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
6.3. Enable Dependency Management in Parent Project
Dependency management is a mechanism for centralizing the dependency information for a muti-module parent project and its children.
When you have a set of projects or modules that inherit a common parent, you can put all the required information about the dependencies in the common pom.xml file. This will simplify the references to the artifacts in the child POMs.
Let’s take a look at a sample parent’s pom.xml:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.3.5.RELEASE</version>
</dependency>
//...
</dependencies>
</dependencyManagement>
By declaring the spring-core version in the parent, all submodules that depend on spring-core can declare the dependency using only the groupId and artifactId, and the version will be inherited:
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
//...
</dependencies>
Moreover, you can provide exclusions for dependency management in parent’s pom.xml, so that specific libraries will not be inherited by child modules:
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</exclusion>
</exclusions>
Finally, if a child module needs to use a different version of a managed dependency, you can override the managed version in child’s pom.xml file:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.2.1.RELEASE</version>
</dependency>
Please note that while child modules inherit from their parent project, a parent project does not necessarily have any modules that it aggregates. On the other hand, a parent project may also aggregate projects that do not inherit from it.
For more information on inheritance and aggregation please refer to this documentation.
6.4. Updating the Submodules and Building a Project
We can change the packaging type of each submodule. For example, let’s change the packaging of the webapp module to WAR by updating the pom.xml file:
<packaging>war</packaging>
Now we can test the build of our project by using the mvn clean install command. The output of the Maven logs should be similar to this:
[INFO] Scanning for projects... [INFO] Reactor build order: [INFO] parent-project [INFO] core [INFO] service [INFO] webapp //............. [INFO] ----------------------------------------- [INFO] Reactor Summary: [INFO] ----------------------------------------- [INFO] parent-project .................. SUCCESS [2.041s] [INFO] core ............................ SUCCESS [4.802s] [INFO] service ......................... SUCCESS [3.065s] [INFO] webapp .......................... SUCCESS [6.125s] [INFO] -----------------------------------------
7. Conclusion
In this article, we discussed some of the more popular features of the Apache Maven build tool.
All code examples on Baeldung are built using Maven, so you can easily check our GitHub project website to see various Maven configurations.