[MNG-5913] Allow defining aliases for existing server configurations in settings.xml#2333
Conversation
|
This needs to be made sure will not break Maven 3, as same settings is shared by both currently. |
7230d9e to
563d2e2
Compare
unit test, looks ok for me. I tested with: |
|
ok, who is willing to work on it with me? I hope such feature will be valuable. |
|
Well, settings with current 3.9.9 are NOT read: Or this is "ok"? Is settings loaded partially or discaded? |
|
I am willing to jump in as Njord does something similar, but my concern is that Maven 3.x is not "forgiving" while readint |
it is correct because 3.9.x does not have it yet |
I hope we can have next version of settings schema for 3.9.x ... so if someone update own settings alos will use newer version of Maven |
Pankraz76
left a comment
There was a problem hiding this comment.
already very nice.
please give last dedication, to reach infinitive higher-order function.
a959fb0 to
e0b3b6b
Compare
|
@gnodet @Pankraz76 last suggestions applied |
2ef5b3c to
811aa80
Compare
gnodet
left a comment
There was a problem hiding this comment.
Review: [MNG-5913] Allow defining aliases for existing server configurations
This is a well-implemented feature that addresses a real pain point — users who need the same credentials for multiple repository servers currently have to duplicate the entire <server> block.
What looks good
- Dual-layer implementation: Changes in both the v4 API (
impl/maven-impl) and the v3 compat layer (compat/maven-settings-builder) with separate test suites for each. - Alias expansion logic: Correct — each settings file's aliases are expanded within that file before merging. Cross-source ID collisions are handled by the existing merge logic (last-wins).
- Validation coverage: Tests cover basic servers (no aliases), servers with aliases (verifying expansion), duplicate alias detection, alias-equals-server-ID detection, and empty alias validation.
- Schema versioning: The
forcedIOModelVersionbump to1.3.0and<version>1.3.0+</version>on the aliases field follow standard Modello practice for schema evolution. - Deep copy:
Server.newBuilder(server, true)correctly deep-copies all fields (includingconfigurationDOM elements) to aliased servers. - Project settings: Aliases are correctly warned about and stripped from project settings, consistent with how other unsupported features are handled.
Open coordination items
The backward compatibility discussion between @cstamas, @michael-o, and @slawekjaranowski about whether settings.xml files using <aliases> should work across Maven versions is the main open question. This is a policy/coordination decision, not a code issue — the implementation is technically sound.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of Guillaume Nodet
Reviewed 3 PRs: apache#2333 (server aliases, clean), apache#10971 (test, LGTM), apache#11186 (namespace validation, needs rework). 18 reviews total. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
settings.xml is locally managed by users in own controlled environments. Should be not a compatibility problem. So as technically change is ok, should not be block to merge. |
gnodet
left a comment
There was a problem hiding this comment.
Re-review: Allow defining aliases for existing server configurations
Verdict: APPROVE ✅
No new commits since the previous review (2026-07-10). The updatedAt change was triggered by the author's comment (2026-07-11) responding to the backward compatibility discussion.
Author's response to backward compat concern
slawekjaranowski argues that settings.xml is locally managed by users, so adopting the <aliases> feature inherently requires a newer Maven version — this should not block the merge. This is a reasonable position for an opt-in feature in a user-managed file.
Code assessment (unchanged)
The implementation remains clean across all reviewed dimensions:
- Alias expansion correct in both v4 (
DefaultSettingsBuilder) and v3 compat layers - Validation covers: duplicate alias-vs-id, duplicate alias-vs-alias, alias-equals-own-id, empty alias values
- Comprehensive test coverage with dedicated XML fixtures
- Schema versioning (
1.3.0+,forcedIOModelVersion=1.3.0) follows Modello conventions !isProjectSettingsguard and project-settings alias stripping are correct
The remaining backward compat discussion is a project governance decision among committers, not a code issue.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of Guillaume Nodet
…in settings.xml Add the next tag ids to the server in settings.xml Additional server will be created in memory by SettingsBuilder, so the generated configuration should be transparent to other as Settings#getServers() will return complete list.
…ion in `settings.mdo`.
811aa80 to
44b6b2d
Compare
gnodet
left a comment
There was a problem hiding this comment.
Re-review: Server aliases — post-rebase
Verdict: APPROVE ✅
Pure rebase onto latest base branch — same 20 files, same 641+/15−, same 11 commits with identical messages. No code changes. Previous approval stands.
This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.
Claude Code on behalf of Guillaume Nodet
…in settings.xml * [MNG-5913] Allow defining aliases for existing server configurations in settings.xml Add the next tag aliases to the server in settings.xml Additional server will be created in memory by SettingsBuilder, so the generated configuration should be transparent to other as Settings#getServers() will return complete list. Based on commit 09b2dfc #2333
Add the next tag ids to the server in settings.xml
Additional server will be created in memory by SettingsBuilder, so the generated configuration should be transparent to other as Settings#getServers() will return complete list.
https://issues.apache.org/jira/browse/MNG-5913