DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
Things to check before starting a Maven 4.0.0 vote (recommendation) based on "maven-4.0.x" branch .
Discussion thread "[Discussion] What needs to be done for 4.0.0 GA?" on Mailing list
4.0.0-rc-6 milestone tracking
Blocking issues ("bugs")
- issues regarding Build / Consumer parent POMs: see below
Build / Consumer POM
some changes done in RC5 created new blocker issues: https://github.com/apache/maven/issues/11772 (found after JLine released with Maven 4.0.0-RC5 with the new 4.1 model, and other projects started to use the generated consumer POMs from Maven Central)
and tests from public project showed issues:
- with POMs not published to Maven Central: https://github.com/apache/maven/issues/11767
- with profiles https://github.com/apache/maven/issues/11798
Maven 4 API
- Maven API 4 complexity and not final? Do we want to call it "okay as it is" and improve later or do we need/want to get it done before GA?
- See Elliotte https://lists.apache.org/thread/fp5dnsw93x1v3b43qm2y0nqj6zxbljpn (and other post further on the thread)
- Similar to this, Maarten's discussion if Maven 4.0.0 is ready to release ("do we feel comfortable to release 4.0.0 in it's current stat) ?"
- Documentation "how to upgrade plugins to Maven 4 API"? SITE-issue 751
- Not a direct blocker for GA release, but I (Gerd, additions on list by Matthias) think Maven (Plugins) should (always) compile/test with the latest 4.x (at least if they are already ported to 4.x). I made some tries on my local machine (macOS). Some components need 4.x, but seem to only work with specific versions:
Unfortunately, there were API changes between the beta/rcs which require updates of the code.
Therefore, we should also check if the latest published version of each 4.x component, runs with latest 4.x (independent from the version it needs to build). - conclusion discussion end of March 2026: https://lists.apache.org/list.html?dev@maven.apache.org, with small summary by Guillaume
On the @Experimental api, I just want to restate what I had in mind : * release 4.0 without publicizing the new API * finalize 4.x plugins to make them ready for consumption, this could use a few iterations of Maven over the coming months (4.1, 4.2, etc...) * when that's done, remove the @Experimental flag and release all plugins in GA Basically, ship the API in a "tech preview" mode. We don't make the API public, we don't tell people to migrate their plugins yet... But 4.0 brings much more than the API...
- tracking of Maven's Maven 3 plugins build with Maven 4 is the real target for Maven 4.0 (and if possible non-Maven ones, like Mojohaus)
To check on our own plugins that the Maven 3 compatibility in Maven 4 works at scale, and eventually fix a few edge cases
How to:
- Git clone source code for all plugins, using maven-sources instructions
- build plugins latest SNAPSHOT (with their ITs) with a Maven version (with fail at end to see a global report at the end):
cd aggregator/plugins mvn -Prun-its clean verify -fae
hint: you can also use
mvndto get parallel build
Maven 3 builds on Maven 4 compatibility tests
Maven plugins
=> https://github.com/apache/maven-dist-tool/blob/master/src/site/markdown/plugins-maven4.md created with check-plugins-maven4.sh
| category | ok with 4.0.0-rc5 | not ok with 3.10 SNAPSHOT | still to be fixed with 4.0.0-SNAPSHOT | fixed for 4.0.0-rc6 | |
|---|---|---|---|---|---|
| core | 8 | clean, deploy, install, resources, verifier | site, surefire | compiler | |
| packaging | 10 | acr, ejb, jar, jlink, rar, war | ear, jmod, shade | source | |
| reporting | 9 | jxr, changelog, changes, checkstyle, doap, javadoc, jdeps, pmd, pir | |||
| tools | 19 | archetype, artifact, enforcer, antrun, dependency, gpg, invoker, jarsigner, remote-resources, scripting, stage, plugin-tools, scm, release | help, jdeprscan, scm-publish | assembly, toolchains |
Other OSS projects
Guillaume has created an automated test for a looooot of source repositories for many OSS projects if they build on Maven 4: https://github.com/gnodet/maven4-testing/issues
=> tracking progress https://github.com/gnodet/maven4-testing/issues/14270 and followup on 2026-06-02 https://lists.apache.org/thread/211ndr159f5y8wq5kpyn8q3lvfz1nv0h
Maven 4 Namespace
Do we stay with the current state or do we do changes?
- Main discussion (July 2025) with no final decision: https://lists.apache.org/thread/1xmnwgt8q3owsjt8pl2nm4rt5q84zdfc
- Brought up again by Elliotte (February 2026) https://lists.apache.org/thread/fp5dnsw93x1v3b43qm2y0nqj6zxbljpn
- Injected as one aspect of Maarten's discussion if Maven 4.0.0 is ready to release ("do we feel comfortable to release 4.0.0 in it's current stat) ?"
- PRs to document the current state in Maven 3 https://github.com/apache/maven/pull/11809 and Maven 4 https://github.com/apache/maven/pull/11810 (versioned namespace and modelVersion inference, feature added in June 2023 4.0.0-alpha-6)
- PR to change namespace to fixed one from Maven 3 (targets future 4.0.0-rcX, X > 5) https://github.com/apache/maven/pull/10952
- decision?
- VOTE result = continue using new 4.1.0 namespace
Compatibility of 3rd party tools and infrastructure services
- Ask Jetbrains Team about their opinion on Maven 4.0.0 status
- Don't see any blockers (Confirmation mail https://lists.apache.org/thread/8kqd92nhno6o4vm1g4l4v78mqqvjmodn )
- Ask Eclipse IDE Team about their opinion on Maven 4.0.0 status
- Ask VS Code Team about their opinion on Maven 4.0.0 status
- Ask Apache Netbeans Team about their opinion on Maven 4.0.0 status
- Reach out to Apache Commons about test status and/or early adoption or opinions
- Reach out to GitHub
- Only fix a specific subset of tasks (*real* blockers with no known workaround)
- Ask Sonatype/Maven Central their opinion on Maven 4.0.0 status
- Reach out to other dependents of the Maven repository system:
- Bazel
- Gradle
- Ivy
- Bazel
Compatibility of 3rd party "library projects"
- Identify some important stakeholders, projects and power users, maybe JReleaser, Oracle, Eclipse/Apache/IBM/etc. projects etc.
Focus on plugins that have a Maven 4 branch in parallel to the classic Maven 3
not really the focus for Maven 4.0 (which uses Maven 3 plugins), but kept here as a work in progress for future Maven 4.1
| project | does building version 3.x fail with Maven 4? | why does it need a Maven 4-specific? | works with 4.0.0-rc-3 | works with 4.0.0-rc-4 | works with 4.0.0-rc-5 | comment | |
|---|---|---|---|---|---|---|---|
plugins/core-4/maven-clean-plugin | done initially as a test for Maven 4 API | x | |||||
plugins/core-4/maven-compiler-plugin |
| 4.0.0-beta-1 done as test 4.0.0-beta-3 adds Maven 4 module support | it seems "works with 4.0.0-xxx" should be rephrased to "last release done with 4.0.0-xxx" and we should have a separate test to check that last release still works with latest Maven 4.0.0-SNAPSHOT | ||||
plugins/core-4/maven-resources-plugin |
| x | |||||
plugins/core-4/maven-deploy-plugin |
| x | |||||
plugins/core-4/maven-install-plugin | x | ||||||
plugins/core-4/maven-site-plugin |
| not a Maven 4 plugin, but old work in progress for Doxia 2 that finally was release as 3.20+ to avoid confusion | should 3.x branch become master for clarity? DONE on 20260403, https://github.com/apache/maven-sources/pull/42 | ||||
plugins/packaging-4/maven-source-plugin | beta-3 only | ||||||
plugins/packaging-4/maven-jar-plugin | x | ||||||
plugins/maven-plugin-tools | done initially as a test for Maven 4 API | x | |||||
shared/filtering | done as part of maven-resources-plugin 4 | ||||||
shared/reporting-impl | version 4 for Doxia 2, not Maven 4 | ||||||
| Plugins without Maven 4 branch | |||||||
plugins/maven-pmd-plugin | ✅ | ||||||
plugins/packaging/maven-ejb-plugin | PR #212, require fix in Maven 4.0.0 RC6 | ||||||
plugins/packaging/maven-shade-plugin | |||||||
ITs require ForkedLauncher since Embedded3xLauncher does not support Maven 4. 20 ITs blocked by mvn script eval expanding ${...} in CLI arguments (apache/maven#11978). Module Source Hierarchy support tracked in apache/maven-surefire#3345. | |||||||