Upgrade to Maven 4.0.0-rc-6 #12676

Activity

1. slachiewicz

   added

   enhancementNew feature or requestNew feature or request

   on Aug 4, 2026
2. slachiewicz

   self-assigned this

   on Aug 4, 2026
3. slachiewicz commented on Aug 4, 2026

   

   slachiewicz

   on Aug 4, 2026

   MemberAuthor

   More actions

   Status and remaining work

   28 of 35 pull requests merged. Every repository that referenced a pre-rc-6 Maven 4 version is now either merged or has an open PR — there is nothing left to find.

   Still open

   PR	State
   apache/maven-mvnd#1714	approved. The four GraalVM Build native distribution jobs fail on master too (undefined reference to stat@GLIBC_2.17 on ubuntu-24.04-arm), so that red is not from this change; apache/maven-mvnd#1712 is the fix for it
   apache/maven-resources-plugin#500	approved. Carries the <skip> workaround for the shadowed-parameter bug, with a TODO pointing at #12626, which fixes the cause in the core configurator
   apache/maven-source-plugin#315	awaiting review. Migration off 4.0.0-beta-3 onto the SourceRoot model; all 23 ITs pass
   apache/maven-executor#35	awaiting review
   apache/maven-dist-tool#202	awaiting review. Rewrites the master-jobs report as a sorted table and fixes a broken status icon (&#2754; is decimal 2754 = U+0AC2, a Gujarati vowel sign, not U+2754)

   Jenkins verification in progress

   All 93 master and 3.x jobs in maven-box were rerun after the shared-library fixes landed. This mattered because only 4 of the 95 jobs had run at all since apache/maven-jenkins-lib#22 changed how Maven is provisioned — every other green result predated it.

   So far: 17 finished, all green; 76 still building; no failures.

   The mechanism is confirmed working. From maven-clean-plugin master #57:

   + mvn ... maven-wrapper-plugin:3.3.4:wrapper -Dmaven=4.0.0-rc-6
   + ./mvnw ...
   Apache Maven 4.0.0-rc-6 (6a8189b24518daa120539fa41ce12f2b48ec09a8)
   Maven home: /home/jenkins/.m2/wrapper/dists/apache-maven-4.0.0-rc-6/2fa31093
   [INFO] BUILD SUCCESS
   

   Note the node's own maven_4_latest still resolves to 4.0.0-rc-5 — the build runs on rc-6 purely through the wrapper. An INFRA request to install rc-6 on the build nodes is therefore no longer needed for these builds.

   Known issues that are not part of this upgrade

   • maven-testing: deprecated org.apache.maven.api.plugin.testing annotations compile but are silently ignored #12678 — the deprecated org.apache.maven.api.plugin.testing annotations still compile but are silently ignored by the relocated MojoExtension, so a plugin that has not moved its imports keeps building and quietly stops reading its test POMs. Also covers ProducedArtifactStub's shim losing its five-argument constructor.
   • Fix field cache to let child class fields take precedence over parent #12626 — EnhancedCompositeBeanHelper.buildFieldCache() lets a parent field shadow a child's, which is what breaks <skip> on testResources. Once released, the workaround in maven-resources-plugin#500 can be removed.
   • maven_4_latest on the ASF build nodes still points at 4.0.0-rc-5. Not blocking anything now, but worth an INFRA ticket for anything that bypasses the wrapper.
4. slachiewicz commented on Aug 4, 2026

   

   slachiewicz

   on Aug 4, 2026

   MemberAuthor

   More actions

   Jenkins rerun complete — 90 of 93 finished, 85 green

   All master and 3.x jobs in maven-box were rerun after the shared-library fixes. Five did not come back green; here is what each one is, since only one of them is actually caused by this work.

   Job	Cause	Ours?
   maven-resources-plugin/master #175	UNSTABLE — MRESOURCES-131 FAILED, 26 ITs passed	No, and apache/maven-resources-plugin#500 fixes it. The IT has been failing since 4.0.0-rc-5
   maven-shared-utils/master #191	UNSTABLE — also unstable in #188 and #189, before the rerun	No, pre-existing
   maven-surefire/master #485	E2ETest.endToEndTest failed. No wrapper or version-resolution errors in the log; #484 was green yesterday	No, unrelated to the wrapper change
   maven-reporting-impl/maven-reporting-impl-3.x #5	Could not find artifact org.apache.maven.doxia:doxia-sink-api:jar:1.12.0-SNAPSHOT	No, a stale SNAPSHOT dependency
   maven-reporting-api/maven-reporting-api-3.x #4	apache-rat: Too many files with unapproved license: 1	Yes — see below

   The RAT failure is a side effect of provisioning the wrapper

   Since apache/maven-jenkins-lib#22, every build generates the Maven wrapper into the workspace before building. That writes three files, and they are not equal in the eyes of apache-rat:

   • mvnw — carries an ASF licence header
   • mvnw.cmd — carries an ASF licence header
   • .mvn/wrapper/maven-wrapper.properties — no header, just wrapperVersion / distributionType / distributionUrl

   Exactly one unlicensed file, which matches the count RAT reports.

   It only fails where the RAT configuration does not exclude it. maven-reporting-api-3.x inherits maven-shared-components:34, which predates the wrapper; the same repository's master is on maven-shared-components:49 and passes. So this will affect old maintenance branches on old parents, and leave modern branches alone — 1 job out of 93 here.

   Worth deciding how to handle it rather than leaving it to surface repo by repo:

   1. have the shared library exclude the generated file when it invokes the build,
   2. have maven-wrapper-plugin emit a licence header in maven-wrapper.properties, which fixes it everywhere at once, or
   3. leave it, and let affected maintenance branches add a RAT exclusion when someone touches them.

   What the rerun did confirm

   85 green, including every repository in this upgrade, on both asfMavenTlpPlgnBuild and asfMavenTlpStdBuild, on Maven 3 and Maven 4 branches alike. Builds provision 4.0.0-rc-6 through the wrapper while the nodes still resolve maven_4_latest to 4.0.0-rc-5.
5. slachiewicz commented on Aug 4, 2026

   

   slachiewicz

   on Aug 4, 2026

   MemberAuthor

   More actions

   Checking which Maven 3 plugins already build on Maven 4

   A separate, follow-on batch: rather than upgrading anything, these just turn on Maven 4 verification so we learn where the Maven 3 plugins stand ahead of GA. Same one-line change as apache/maven-javadoc-plugin#1350.

   maven4-enabled: true appends 4.0.0-rc-6 to the existing Maven 3 matrix — the plugin is still built and tested with Maven 3, and additionally checked against Maven 4. The shared workflow excludes the {jdk: 8, maven: 4.x} cell automatically.

   PR	plugin
   apache/maven-acr-plugin#144	packaging
   apache/maven-shade-plugin#837	packaging
   apache/maven-war-plugin#644	packaging
   apache/maven-gpg-plugin#330	tools
   apache/maven-toolchains-plugin#192	tools
   apache/maven-scripting-plugin#80	tools
   apache/maven-remote-resources-plugin#288	tools
   apache/maven-doap-plugin#164	reporting
   apache/maven-checkstyle-plugin#677	reporting
   apache/maven-project-info-reports-plugin#645	reporting

   A red Maven 4 cell on any of these is the useful outcome — better found now than at GA.

   Consistency fix on the Maven 4 side

   Two of the Maven-4-native plugins hand-rolled the matrix instead of using the switch the shared workflow provides:

   -      ff-maven: "4.0.0-rc-6"                     # Maven version for fail-fast-build
   -      maven-matrix: '[ "4.0.0-rc-6" ]'
   +      maven4-build: true
   +      maven4-version: '4.0.0-rc-6' # the same as used in project

   PR
   apache/maven-resources-plugin#502
   apache/maven-jar-plugin#576

   Same result, but the version stops being repeated in two places and re-pinned on every RC, and the {jdk: 8} exclude comes for free rather than depending on jdk-matrix happening to be [17, 21]. The other seven Maven 4 plugins — clean, install, deploy, compiler, source, archiver, filtering — already use maven4-build.

   Audit notes

   All 36 repositories currently passing maven4-enabled: true were checked against their POMs and are genuinely Maven 3 code (prerequisites 3.6.3, mavenVersion 3.9.x, no maven-api-* dependencies), so the flag is right in every one. plugin-tools looked like an exception at version 4.0.0-beta-3-SNAPSHOT, but no module depends on maven-api-* and it pins both maven3Version and maven4Version, so maven4-enabled is correct there too.

   One trap worth recording for anyone doing more of these: with maven4-enabled the shared workflow pipes matrix-exclude through jq, which rejects a trailing comma. Without the flag the value is echoed verbatim, so invalid JSON sits there harmlessly until the flag is added. Every repository in this batch was checked for it first.
6. slachiewicz commented on Aug 4, 2026

   

   slachiewicz

   on Aug 4, 2026

   MemberAuthor

   More actions

   Results from turning on Maven 4 verification

   Eight of the ten merged green, so those plugins build and test clean on 4.0.0-rc-6 with no changes: maven-acr-plugin#144, maven-toolchains-plugin#192, maven-scripting-plugin#80, maven-doap-plugin#164, maven-project-info-reports-plugin#645, maven-remote-resources-plugin#288, plus the two consistency fixes maven-resources-plugin#502 and maven-jar-plugin#576. maven-war-plugin#644 and maven-checkstyle-plugin#677 are still running.

   Two turned up genuine Maven 4 problems. In both cases the failure is only on the 4.0.0-rc-6 matrix cell — the Maven 3 cells that completed passed, and fail-fast cancelled the remainder. Neither is caused by the workflow change; it just made them visible, which was the point.

   maven-gpg-plugin#330 — the build POM gets signed

   IT sign-release-with-excludes, 12 passed / 1 failed:

   java.lang.Exception: Unexpected file
     target/local-repo/org/apache/maven/its/gpg/srwe/test/1.0/test-1.0-build.pom.asc
   

   Maven 4 installs both a consumer POM and a build.pom. The plugin signs the build POM too, so a -build.pom.asc appears that the IT's expected-file list — written before Maven 4 — does not know about.

   Two readings, and it is worth someone deciding which:

   • the IT simply needs to learn about Maven 4's dual-POM install, or
   • signing the build POM is wrong. It is an internal artifact rather than something consumers resolve, so a signature for it may not belong in the repository at all.

   The second is the more interesting possibility and should be settled before GA, since it affects what every released artifact looks like.

   maven-shade-plugin#837 — uber jar missing under Maven 4

   IT MSHADE-374_testJarArtifactSet, 83 passed / 1 failed:

   java.nio.file.NoSuchFileException:
     target/it/MSHADE-374_testJarArtifactSet/uber/target/mshade-374-uber-1.0.jar
   

   The uber jar is not produced. That IT covers artifactSet with a test-jar specifically, so artifact selection behaving differently under Maven 4 is the more likely cause than anything in the shading itself. Not diagnosed further.

   Both PRs are being left open with the failures on record, rather than reverted — the red cell is the finding.
7. slachiewicz

   assigned

   gnodet

   on Aug 4, 2026
8. slachiewicz

   closed this as completedon Aug 8, 2026
9. slachiewicz commented on Aug 8, 2026

   

   slachiewicz

   on Aug 8, 2026

   MemberAuthor

   More actions

   Closing out the Maven 4 verification batch

   Nine of the ten are merged; the tenth was closed as a duplicate. Both of the genuine Maven 4 failures reported above have moved, one of them only halfway.

   maven-gpg-plugin#330 — merged, but only one of the two questions is settled

   The IT side is fixed. apache/maven-gpg-plugin#332 teaches sign-release-with-excludes about the POM pair, and #330 was rebased on top of it and merged with all 17 jobs green, including all six 4.0.0-rc-6 cells — macOS, Ubuntu and Windows on both JDK 21 and 25. The cell that failed before (macos-latest jdk-21-zulu 4.0.0-rc-6) is green.

   That is the first of the two readings above. The second is still open: whether the build POM should be signed at all. #332 only taught the test what Maven 4 currently does; it did not decide that what Maven 4 currently does is right. If that question is later answered "no", the two lines to revert are the test-1.0-build.pom / test-1.0-build.pom.asc entries added to src/it/sign-release-with-excludes/verify.groovy.

   Some detail from confirming the behaviour locally, since it narrows the question. Running the IT against Maven 4 and Maven 3.9.16 with a clean target each time, the installed directory is:

   maven 3                    maven 4
   _remote.repositories       _remote.repositories
                              test-1.0-build.pom        <- the project's own pom.xml
                              test-1.0-build.pom.asc
   test-1.0.jar               test-1.0.jar
   test-1.0.jar.asc           test-1.0.jar.asc
   test-1.0.pom               test-1.0.pom              <- the consumer pom under maven 4
   test-1.0.pom.asc           test-1.0.pom.asc
   

   So the build POM is genuinely Maven-4-only, and those two files are the only difference — nothing else about the signed set changes. Note also that under Maven 4 the consumer POM is what occupies the plain test-1.0.pom name, so a consumer resolving test:1.0 gets the consumer POM and its signature either way. That is what makes the build POM signature arguable: it is an extra artifact a consumer does not normally fetch.

   One incidental find while fixing the IT: the //maven4: skip consumer POM guard in that script had silently stopped matching anything. It was written for an earlier Maven 4 that installed the consumer POM as *-consumer.pom; the suffix now belongs to the build POM instead. Removed in #332. Worth checking for the same stale guard in any other repository that grew a Maven 4 workaround in that window.

   maven-shade-plugin#837 — closed, and the finding now has no PR carrying it

   Closed on 5 August as a duplicate of apache/maven-shade-plugin#810 ("enable build with Maven 4"), which is still open. That means the uber-jar failure recorded above — MSHADE-374_testJarArtifactSet producing no mshade-374-uber-1.0.jar under Maven 4 — is no longer attached to an open PR in this batch, so it is worth restating here so it does not get lost. apache/maven-shade-plugin#813 (<relativePath/> in dependency-reduced-pom.xml causing a false parent cycle under Maven 4) suggests shade has more than one Maven 4 problem to work through.

   The two that were still running

   Both green and merged: apache/maven-war-plugin#644 and apache/maven-checkstyle-plugin#677.

   Where the batch stands

   PR	Result
   apache/maven-acr-plugin#144	merged, green
   apache/maven-war-plugin#644	merged, green
   apache/maven-toolchains-plugin#192	merged, green
   apache/maven-scripting-plugin#80	merged, green
   apache/maven-remote-resources-plugin#288	merged, green
   apache/maven-doap-plugin#164	merged, green
   apache/maven-checkstyle-plugin#677	merged, green
   apache/maven-project-info-reports-plugin#645	merged, green
   apache/maven-gpg-plugin#330	merged, green — needed apache/maven-gpg-plugin#332 first
   apache/maven-shade-plugin#837	closed as a duplicate of #810; the uber-jar failure is unresolved

   Eight of these ten plugins build and test clean on 4.0.0-rc-6 with no product changes. One needed only a test taught about Maven 4. One has a real failure still to diagnose.