Know one Maven project, know them all

Maven builds a Java project from its pom.xml and a set of plugins: it fetches the libraries the project declares, then compiles, tests and packages in the same order on every machine.

Create your first project Download Maven 3.10.0

pom.xml

<project>
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.example</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0</version>
</project>

my-app/

├── pom.xml
└── src/main/java/
    └── com/example/
        └── App.java

$ mvn verify
[INFO] --- resources:3.5.0:resources (default-resources) @ my-app ---
[INFO] --- compiler:3.16.0:compile (default-compile) @ my-app ---
[INFO] --- surefire:3.6.0:test (default-test) @ my-app ---
[INFO] --- jar:3.5.1:jar (default-jar) @ my-app ---
[INFO] BUILD SUCCESS

The POM only names the project; the convention says where the code is. The build is Maven 3.10.0’s own output.

Maven 3.10.0 Current release, recommended for all users Download · Release notes
Maven 3.9.16 Previous line, 3.9, still maintained Download · Release notes
Maven 4.0.0-rc-7 Preview of Maven 4, not yet final Download · Release notes

What Maven does

Dependency management, made boring

Declare each library by its coordinates, group, name and exact version, and Maven fetches it and what it depends on from Maven Central.

One version of each library, fixed in one place for all your modules.
A new release reaches your build only when you change a version.
Downloads over HTTPS by default since Maven 3.8.1, and downloading a library runs none of its code.

Automate upgrades with the Versions Maven Plugin from MojoHaus, and review the diff.

How dependencies work

<dependency>
  <groupId>org.apache.commons</groupId>
  <artifactId>commons-lang3</artifactId>
  <version>3.17.0</version>
</dependency>

$ mvn versions:display-dependency-updates
[INFO]   org.apache.commons:commons-lang3 ... 3.17.0 -> 3.21.0
$ mvn versions:use-latest-releases   # updates the POM; review the diff

Builds, made exceptionally boring

Yes, it’s XML, and yes, you write versions down instead of letting them float. Here is what you get for it: build the same sources twice and you get the same JAR, byte for byte. Since Maven 3.10 reproducible builds are on by default.

Reproducible builds

$ mvn clean package && sha256sum target/my-app-1.0.jar
0b9b589c9d53…  target/my-app-1.0.jar
$ mvn clean package && sha256sum target/my-app-1.0.jar
0b9b589c9d53…  target/my-app-1.0.jar

Compile, test, package, repeat

Every Maven project builds through the same main phases, in the same order, on your laptop and in CI. Learn them once, and you can build any Maven project you clone. With the Maven Wrapper the build also runs on the same Maven: ./mvnw verify.

Phases, goals and plugins

validate → compile → test → package
         → verify → install → deploy

$ mvn verify   # validate … verify, in order

There’s a plugin for that

Compiling, testing and packaging are plugins, and so are many other jobs: a runnable JAR, a project site, signed artifacts for a release. Many you run straight from the command line; others you add to the POM and configure like any other.

Buildcompile and test your code: clean compiler resources surefire failsafe install
Packageturn it into something to ship: jar war shade assembly jlink
Checkhold the build to your rules: enforcer checkstyle pmd
Inspectsee what Maven sees: dependency help
Releasepublish what you built: source javadoc gpg release deploy
Sitedocument the project: site project-info-reports

47 Apache Maven plugins, and many more from MojoHaus and others

Big builds, one command

Split an application into modules and one mvn verify from the root of your project builds them all, each after the modules it depends on. Working on one? -pl picks a module by its directory, -am adds the modules it depends on, and -T builds independent modules in parallel.

Build part of a project

$ mvn verify             # every module, in order
$ mvn -pl app -am verify # app and what it needs
$ mvn -T 1C verify       # independent modules in parallel

Faster builds with mvnd

The Maven Daemon keeps Maven running between builds, so the next build starts warm. Install it next to Maven, then type mvnd instead of mvn: same projects, same goals.

Maven Daemon