Migrate to Maven 4
With the upcoming release of Maven 4.0.0, we should begin evaluating the compatibility of its release candidates with Log4j. Maven 4 introduces several significant changes that are highly relevant to our build and release process.
Key Benefits for Log4j
1. Separation of Build and Consumer POMs
Maven 4 formally introduces a clean separation between the build POM (used during the build process) and the consumer POM (published to Maven Central).
Currently, we use the Flatten Maven Plugin to publish a simplified version of our log4j-bom, which removes build-related metadata and retains only the dependency management section. However, this approach is fragile—stripping too much information can lead to broken or unresolvable artifacts. This has already contributed to several issues, including:
- apache/logging-parent#37
- #3758
- #3779
Migrating to Maven 4’s Consumer POM model would eliminate the need for these manual workarounds by making the separation between build and published metadata a first-class feature, managed directly by Maven.
2. CI-Friendly Versioning
Maven 4 introduces support for automatic versioning of submodules in multi-module builds. This would offer a more robust alternative to our current usage of the revision property and Flatten Maven Plugin, further simplifying our build process.
This should be an interesting build update. IntelliJ has some Maven 4 support now, so IDEs aren't a blocker. Do we still want to use the XML format, or is there a better format available in Maven 4?
We probably want to upgrade to the 4.1.0 XML schema for POM files.
I tried that a couple of months ago, but I encountered some problems with dependency version resolution, which ended up triggering the requireUpperBoundDeps Maven Enforcer rule. I didn't investigate this further.
Please stick to XML – logging-parent has some XML-specific machinery over pom.xml. Slightly related: our changelog entry file format is in XML too.
Please stick to XML –
logging-parenthas some XML-specific machinery overpom.xml. Slightly related: our changelog entry file format is in XML too.
That's a good point. We have sufficient XML tooling in place that it makes sense to keep using.