Re: [I] Upgrade to Maven 4.0.0-rc-6 [maven]

2026-08-08 Thread via GitHub


slachiewicz commented on issue #12676:
URL: https://github.com/apache/maven/issues/12676#issuecomment-5225477218

   ## 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 3maven 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 (`` 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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] Upgrade to Maven 4.0.0-rc-6 [maven]

2026-08-08 Thread via GitHub


slachiewicz closed issue #12676: Upgrade to Maven 4.0.0-rc-6
URL: https://github.com/apache/maven/issues/12676


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] Upgrade to Maven 4.0.0-rc-6 [maven]

2026-08-04 Thread via GitHub


slachiewicz commented on issue #12676:
URL: https://github.com/apache/maven/issues/12676#issuecomment-5184289162

   ## 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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] Upgrade to Maven 4.0.0-rc-6 [maven]

2026-08-04 Thread via GitHub


slachiewicz commented on issue #12676:
URL: https://github.com/apache/maven/issues/12676#issuecomment-5184032621

   ## 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:
   
   ```diff
   -  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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] Upgrade to Maven 4.0.0-rc-6 [maven]

2026-08-04 Thread via GitHub


slachiewicz commented on issue #12676:
URL: https://github.com/apache/maven/issues/12676#issuecomment-5181247303

   ## 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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]



Re: [I] Upgrade to Maven 4.0.0-rc-6 [maven]

2026-08-04 Thread via GitHub


slachiewicz commented on issue #12676:
URL: https://github.com/apache/maven/issues/12676#issuecomment-5179692718

   ## 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 `` 
workaround for the shadowed-parameter bug, with a `TODO` pointing at 
apache/maven#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 (`ૂ` 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
   
   - apache/maven#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.
   - apache/maven#12626 — `EnhancedCompositeBeanHelper.buildFieldCache()` lets 
a parent field shadow a child's, which is what breaks `` 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.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]