Maven 4 Officially Announced: A 15‑Year Overhaul of Java’s Build Tool

Why Maven 4 Matters

Since Maven 3’s 2010 launch, the Java ecosystem has transformed—modularization, parallel builds, cloud‑native containers, and rapid JDK releases—yet Maven itself remained largely unchanged. Maven 4 is designed to shed this legacy weight.

Release Status

Maven 4 has progressed to the fifth release candidate (RC5). Although a final GA date is not announced, the project’s maturity and stability suggest an imminent official release.

POM Model Upgrade

The POM modelVersion is upgraded from 4.0.0 to 4.1.0. Maven 4 remains backward‑compatible with existing 4.0.0 POMs, but new capabilities only activate when the modelVersion is 4.1.0. In many cases the modelVersion element can be omitted because Maven derives it from the schema.

<project xmlns="http://maven.apache.org/POM/4.1.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.1.0
                             http://maven.apache.org/xsd/maven-4.1.0.xsd">
  <modelVersion>4.1.0</modelVersion>
</project>

Build POM vs Consumer POM (Flattening)

In Maven 3 a published POM bundles plugin configuration, build details, parent references, and assorted properties, forcing consumers to parse irrelevant information. Maven 4 introduces native POM flattening, separating the artefacts used for building the project (Build POM) from those published to downstream consumers (Consumer POM).

Build POM: used for the project’s own build.

Consumer POM: provided to dependents.

Consumer POM characteristics:

No plugin configuration.

No parent POM.

No unused dependencies.

Only real transitive dependencies are retained.

Properties are resolved to concrete values.

Enable flattening with:

mvn clean install -Dmaven.consumer.pom.flatten=true

In Maven 3 this required the external Flatten Maven Plugin; Maven 4 provides it as a built‑in capability, resulting in faster, cleaner, and more predictable dependency resolution.

New Artifact Types for Explicit Classpath Control

Maven 3 inferred the classpath/module path based on the presence of module-info.class, which was ambiguous in the Java module era. Maven 4 adds explicit types:

<type>classpath-jar</type>
<type>module-jar</type>

Developers can now declare precisely where a dependency belongs. Maven 4 also introduces dedicated annotation‑processor types:

processor

classpath-processor

modular-processor

Example with Lombok:

<dependency>
  <groupId>org.projectlombok</groupId>
  <artifactId>lombok</artifactId>
  <version>${lombok.version}</version>
  <type>classpath-processor</type>
</dependency>

<dependency>
  <groupId>org.projectlombok</groupId>
  <artifactId>lombok</artifactId>
  <version>${lombok.version}</version>
  <scope>provided</scope>
</dependency>

Maven 4 clearly separates API classpath from processor classpath, improving build semantics and tool‑chain optimisation.

Modules Renamed to Subprojects

Java 9’s module system left many developers confused by the overlapping concepts of Maven modules and Java modules. Maven 4 deprecates the old modules element and replaces it with subprojects:

<subprojects>
  <subproject>project-a</subproject>
  <subproject>project-b</subproject>
</subprojects>

Additional improvements:

Parent inference: an empty <parent/> is auto‑detected.

Automatic subproject discovery without explicit declaration.

Unified build timestamps.

Safe release: a failure in any subproject aborts the entire release.

Tree‑Based Lifecycle for Parallel Builds

Maven 3’s linear lifecycle made efficient parallelism difficult for large multi‑module projects. Maven 4 introduces a tree‑based lifecycle where each subproject progresses independently once its dependencies are ready, dramatically speeding up builds.

Activate with:

mvn -b concurrent verify

Configuration Enhancements

Conditional Profile Expressions

Profiles can now use full expressions instead of simple OS or JDK checks:

<condition>
  exists('${project.basedir}/src/**/*.xsd') &&
  length(${user.name}) > 5
</condition>

Unified sources Model

The old sourceDirectory and testSourceDirectory elements are replaced by a unified sources container that specifies scope and directory for each source set.

<sources>
  <source>
    <scope>main</scope>
    <directory>my-custom-dir/foo</directory>
  </source>
  <source>
    <scope>test</scope>
    <directory>my-custom-dir/bar</directory>
  </source>
</sources>

This model better supports multiple directories, multiple versions, modular projects, and scenarios without plugin configuration.

Official Upgrade Assistant

Maven 4 ships with mvnup, a tool that analyses the existing POM, plugins, and project structure and generates executable upgrade suggestions.

mvnup check   # generate a report only
mvnup apply   # automatically apply changes

The tool inspects the POM, plugins, and project layout, then proposes concrete modifications to migrate to Maven 4.

Overall Impact

Maven 4 delivers a dual upgrade: a semantic overhaul (new POM model, explicit artifact types, subproject terminology) and an engineering overhaul (flattened consumer POMs, parallel‑friendly lifecycle, richer configuration). The changes aim to align the build system with modern Java development practices and to make large, modular builds faster and more reliable.