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