Skip to content

Build against Maven 4.0.0-rc-6 - #1714

Merged
slachiewicz merged 5 commits into
apache:masterfrom
slachiewicz:maven-4.0.0-rc-6
Aug 4, 2026
Merged

Build against Maven 4.0.0-rc-6#1714
slachiewicz merged 5 commits into
apache:masterfrom
slachiewicz:maven-4.0.0-rc-6

Conversation

@slachiewicz

@slachiewicz slachiewicz commented Aug 4, 2026 •
edited
Loading

Copy link
Copy Markdown
Member

Moves maven.version to the current RC, and the wrapper distributionUrl with it so the two do not drift apart.

Note: this repo's workflows only trigger on pushes to master/mvnd-1.x and on pull_request, so it could not be pre-verified on a fork branch — CI runs here on the PR.

@slachiewicz @claude
Build against Maven 4.0.0-rc-6
b0c0b64 
Move maven.version to the current RC, and the wrapper's distributionUrl
with it so the two do not drift apart.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gnodet
gnodet requested changes Aug 4, 2026
View reviewed changes

@gnodet gnodet left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR bumps maven.version to 4.0.0-rc-6 but does not update the companion dependency properties explicitly marked <!-- Keep in sync with Maven --> in pom.xml:

Property Current (this PR) Maven rc-6 ships
maven.resolver.version 2.0.20 2.0.21
slf4j.version 2.0.17 2.0.18
jline.version 3.30.16 4.3.1

The JLine gap is especially significant — Maven rc-6 moves from JLine 3.x to 4.x, which includes artifact renames (e.g. jline-terminal-jansi → jansi-core). The current pom.xml still declares dependencies on the old JLine 3.x artifact names, so bumping maven.version alone risks build failures or runtime classpath conflicts.

Note: PR #1696 by @gnodet already handles the full rc-6 upgrade comprehensively — including all synced dependencies, artifact renames, and provisio assembly changes — and appears to supersede this PR.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of @gnodet

Comment thread pom.xml
@slachiewicz @claude
Align slf4j with the Maven 4.0.0-rc-6 distribution
033626d 
rc-6 ships slf4j 2.0.18. With mvnd still on 2.0.17 the assembled distro
carries both, and DistroIT.noDuplicateJars fails:

  contains duplicates jars[[jul-to-slf4j-2.0.18.jar, jul-to-slf4j-2.0.17.jar]]

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@slachiewicz slachiewicz mentioned this pull request Aug 4, 2026
Closed
@slachiewicz @claude
Sync the "Keep in sync with Maven" properties with rc-6
be08730 
The rc-6 distribution ships resolver 2.0.21 and JLine 4.3.1, while this
pom pinned 2.0.20 and 3.30.16. The native-image classpath showed the split
plainly: resolver transport-file/transport-apache/named-locks at 2.0.21
coming from Maven's own poms next to api/spi/util/impl/connector-basic at
2.0.20 pinned here, and JLine 4.3.1 reader/style/builtins/console next to
3.30.16 terminal/native/terminal-jni.

JLine 4 renames jline-terminal-jansi to jansi-core, so the dependencyManagement
entry moves with it — there is no jline-terminal-jansi jar in the rc-6
distribution and jansi-core-4.3.1.jar is there instead.

Drops <jansi.version> while here: nothing in the tree references it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@slachiewicz

slachiewicz commented Aug 4, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Thanks — the three synced properties were right and are now all in: slf4j.version 2.0.18, maven.resolver.version 2.0.21, jline.version 4.3.1, plus the jline-terminal-jansi → jansi-core rename in dependencyManagement and the removal of the dead <jansi.version> (nothing in the tree references it). Confirmed against the rc-6 distribution itself: jansi-core-4.3.1.jar is present, there is no jline-terminal-jansi jar, and resolver/slf4j are at 2.0.21/2.0.18.

On #1696 superseding this one — I do not think it does, on three counts:

  • it sets maven.version to 4.0.0-SNAPSHOT (plus apache-snapshots <repositories>/<pluginRepositories> blocks), not the released 4.0.0-rc-6. Its title says "upcoming rc-6" — it was written on 27 July, before rc-6 existed.
  • it does not touch .mvn/wrapper/maven-wrapper.properties, so the repo would still build itself with rc-5 while targeting rc-6.
  • it is a draft, mergeable: false / rebaseable: false against a base from a week ago (it diffs from jline 3.30.13 and resolver 2.0.18, whereas master is now on 3.30.16 and 2.0.20), and it has no CI runs at all.

Happy to be overruled if the intent is to track 4.0.0-SNAPSHOT rather than pin the release — but in that case the wrapper still needs updating separately.

One note on the remaining red: the GraalVM Build native distribution jobs fail on master too (run 30862194274 on 67d0a23, undefined reference to stat@GLIBC_2.17 on ubuntu-24.04-arm), so that failure is not from this PR. #1712 is the fix for that one.

gnodet
gnodet reviewed Aug 4, 2026
View reviewed changes

@gnodet gnodet left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for updating slf4j.version to 2.0.18 — that aligns with Maven rc-6.

One remaining item: maven.resolver.version is still at 2.0.20, but Maven 4.0.0-rc-6 ships 2.0.21. This property is under the <!-- Keep in sync with Maven --> comment, so it should be bumped as well.

Regarding my previous comment about jline.version — upon closer review, that property is in the general dependency versions section, not under the "Keep in sync" comment, and mvnd was already using a different JLine version than Maven before this PR. The JLine 3.x→4.x migration is a larger effort tracked separately (PR #1696). Apologies for the noise on that one.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of @gnodet

Comment thread pom.xml
gnodet
gnodet approved these changes Aug 4, 2026
View reviewed changes

@gnodet gnodet left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All previously raised concerns are now addressed:

  • ✅ maven.resolver.version bumped to 2.0.21 (matching Maven rc-6)
  • ✅ slf4j.version bumped to 2.0.18 (from previous commit)
  • ✅ JLine 3→4 artifact rename (jline-terminal-jansi → jansi-core) with jansi.version property removed
  • ✅ Stale staging repository (maven-2247) cleaned up

All "Keep in sync with Maven" properties verified correct against the Maven 4.0.0-rc-6 parent POM. LGTM!

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of @gnodet

@slachiewicz @claude
Let the Maven distribution supply jul-to-slf4j
2ef67ca 
The assembly unpacks apache-maven's bin tarball into /mvn and then adds
org.slf4j:jul-to-slf4j into /mvn/lib separately. While mvnd pinned 2.0.17
and Maven shipped 2.0.18 the two landed side by side — the duplicate
DistroIT.noDuplicateJars was reporting. Now that slf4j is aligned to
2.0.18 the file names collide and provisio fails outright:

  Conflict: artifact org.slf4j:jul-to-slf4j:jar:2.0.18 would overwrite
  existing file: jul-to-slf4j-2.0.18.jar

Maven's own distribution already provides the jar in that directory, so
drop the explicit entry. Verified on a clean build: /mvn/lib holds exactly
one jul-to-slf4j-2.0.18.jar, and no jar name appears twice in the distro.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
gnodet
gnodet approved these changes Aug 4, 2026
View reviewed changes

@gnodet gnodet left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New commit 2ef67ca1 removes the bundled jul-to-slf4j from the provisio descriptor — correct, since Maven 4.0.0-rc-6 supplies it in its own distribution. Avoids duplicate JARs.

All five commits remain focused and well-scoped: Maven rc-6 bump, dependency alignment (resolver 2.0.21, slf4j 2.0.18), JLine 3→4 rename, stale staging repo cleanup, and now jul-to-slf4j deduplication. LGTM!

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of @gnodet

@slachiewicz
slachiewicz merged commit 2d142a2 into apache:master Aug 4, 2026
2 of 6 checks passed
@slachiewicz
slachiewicz deleted the maven-4.0.0-rc-6 branch August 4, 2026 15:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@gnodet gnodet gnodet approved these changes

Assignees

No one assigned

Labels

maintenance

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@slachiewicz @gnodet