Maven 4 is on the horizon, with Release Candidate 2 (RC2) already available for early adopters. While an official release date is still unknown, at least one more RC (RC3) is expected. If you're working with Maven-based projects, now is a great time to test out the new version and prepare for the transition.
I have had it installed for a couple of months already. So far, I haven’t seen any big issues with it (which is good, I guess). My Vaadin projects and add-ons build fine with it as well. I only see a few more warnings that I should probably fix even if staying with Maven 3. But in a recent JFokus 2025 session by Anders Hammar and Robert Scholte, I learned a bunch of details about why we should actually be at least a bit excited about it. Let me summarise my findings.
Key changes
Maven 4 maintains strong compatibility with existing projects, so upgrading should be relatively smooth. However, some changes will impact the way projects are built and managed:
- Separation of build and consumer POMs: Previously, all build details and test dependencies were included in the distributed
pom.xml, even though they weren’t relevant to consumers. Some projects used themaven-flatten-pluginto strip these out as a workaround. With Maven 4, this is now handled automatically. The nice thing is that there is no new version for the consumer pom.xml. It is the same pom.xml format version 4.0.0 that we have been using now for a decade (Maven 3 used pom.xml 4.0). At least in theory, all other tooling that consume information from pom.xml files should not need to be changed. Upgrading the “build pom.xml in your project to the 4.1 version is optional. - Project Local Repository is an additional Maven repository and technically an implementation detail you’ll likely discover exists. It allows, for example, Maven 4 to cope better with multimodule projects. In multimodule projects, the project-local repository will appear in the target folder of your root project. In the package phase, successfully built artifacts are cached there, paving the way for much better functioning incremental builds (now, typically, just using the “-r” flag is enough instead of that infamous “clean install”).
Project Local Repository can also be handy if you want to see what actually ends up to your “consumer POM” discussed above. The location of the project's local repository may initially be a bit of a surprise for you (defaults to the target directory in your home folder). A more appropriate solution is often the top level of your multi-module project. You’ll probably miss it, but the build output actually hints you to configure it: Unable to find the root directory. Create a .mvn directory in the root directory or add the root="true" attribute on the root project's model to identify it. I’d assume the latter to appear on our top-level pom.xml:s, as long as we upgrade to the 4.1 version of the build pom schema - the marker directory can be handy if one builds with both Maven 3 and 4 during the transition period. - Support for 2.0 plugin API is dropped. Unless you are using some very old plugins, this shouldn’t affect anything.
- Requires at least Java 17 to run. But this doesn’t mean you couldn't produce e.g. Java 8 compatible artifacts, you’ll just need Java 17 to execute Maven itself. A best practice in this kind of setup, already with Maven 3 and the modern compiler plugin version, is to use
maven.compiler.releaseinstead of the oldersource/targetdefinitions to catch JDK mismatches early.
Improvements for declaring multi-module projects
Maven 4 introduces several quality-of-life improvements for multi-module projects. As already mentioned before, resuming builds after failing with a module works much better now. But declaring multimodule projects also becomes much nicer. A lot of the repetitive groupIds and version numbers in child modules can now typically be replaced with an empty <parent/> tag. If this convention is used in the build POM, the groupId, version, and parent projects are automatically inherited from the pom.xml in the parent directory.
Maven 4 dramatically removes boilerplate from parent module declarations.
Even if your tooling wrote a lot of that boilerplate, and you probably outsourced version number maintenance to the versions plugin, I feel very good about this change. It is also perfectly backward compatible, as Maven 4 will “fill in the blanks” for the consumer pom files that will be shared to, for example, Maven Central.
Some smaller but noteworthy changes
- Checksum mismatch now fails the build: This ensures broken artifacts don’t linger in your local repository.
- Build can be made to fail on plugin warnings: Allows stricter validation for better build reliability.
- New BOM packaging type: This improves dependency management for projects using Bill of Materials (BOMs).
Why you should try Maven 4 now
Personally, I’ve been testing Maven 4 RC versions since late last year. While there are often some additional warnings, things are mostly backward compatible, and issues/warnings are easy to fix. The improvements for multi-module projects are particularly exciting and will significantly streamline complex builds (I'm going to try this myself). I expect I can also start cleaning up the pom.xmls of my Vaadin add-on libraries and at least get rid of their maven-flatten-plugin, which is now obsolete.
One final thought: I’ve never been a big fan of the Maven wrapper, but for some legacy projects, it might prove useful now during the transition. If your existing setup doesn’t play nicely with Maven 4, the wrapper can provide a practical way to isolate older builds while modernizing the rest of your projects. The cool thing about the wrapper plugin is that your locally installed Maven 4 tooling can install the Maven 3 wrapper to an existing project if it doesn’t work perfectly with Maven 4.
Learn more by watching Anders Hammar and Robert Scholte's session from JFokus 2025 below.