Restrict what a repository-resolved model contributes to the build

[slachiewicz]

A model resolved from a repository should contribute less to the build than the project's own POM.

• Repository precedence. Repositories contributed by a resolved model merge recessively; those supplied by the request or session keep precedence. BUILD_* requests — the project being built — are unaffected.
• Profile activation. For models resolved while building a dependency POM, profiles activated by file, property or condition are skipped, and profiles that do activate contribute no repositories. Settings and CLI profiles are untouched.
• Parent cache partitioning. The resolved-parent cache is keyed by resolution origin, so a parent reached from a dependency chain and the same parent reached from the project's own chain no longer share an entry.
• Property interpolation. A model built while resolving a dependency POM or its parent resolves, from the session properties, only an environment-independent set of expressions: java.*, os.*, maven.*, the three separators, and the CI-friendly revision, changelist and sha1. Everything else, environment variables included, is left as a literal expression. maven.model.dependencyInterpolation.full=true restores the previous behaviour.
• system scope in imported dependency management. Dependency management imported from a POM resolved from a repository no longer contributes entries that declare system scope or a systemPath; those entries are dropped and a warning names them. Management imported from the reactor is unaffected, and so is a system scope declared by the project's own POM. maven.repository.dependencyManagement.allowSystemScope=true restores the previous behaviour.

The last two change behaviour that has been in place for a long time, which is why each ships an opt-out property. MavenITmng4379, MavenITmng4590 and MavenITmng3586 keep their original assertions behind the opt-out and each gains a companion test asserting what the new default does instead. MavenITmng3586#testitFromProject, where the project's own POM declares the system scope, needs no opt-out.

Worth a maintainer's eye on the interpolation default in particular: MNG-4379 has resolved a systemPath from an environment variable in a repository-served POM since 2009, and under the new default such a build fails on the existing "must specify an absolute path" validation rather than resolving.

Which of these applies is decided by the model's source kind rather than by the request type: a model
built from Sources.resolvedSource(...) is one Maven fetched from a repository, while a POM handed to
Maven as a file reports no model id. MavenITmng4765LocalPomProjectBuilderTest covers the latter, and
two unit tests assert a caller-supplied model is left alone.

ModelSource.getModelId() exists on master but not on this branch, so it is added here as a @Nullable default returning null, overridden in Sources.ResolvedPathSource. That is an additive, binary
compatible change to api/maven-api-core, and it keeps this PR and the master one using the same
mechanism. Keying on whether the source has a path would not work: caller-supplied sources report none
either, so it would restrict exactly the models this is meant to leave alone.

Each change is a separate commit.

---

Draft while related code paths are reviewed.

[gnodet]

✅ Well-Designed Security Hardening

Well-structured behavioral change with thorough test coverage and clear opt-out mechanisms. The PR restricts what repository-resolved models contribute to the build, addressing multiple real-world attack vectors (dependency confusion via repository injection, property leaking, profile-based side effects).

The test coverage is excellent: unit tests for both compat and new model builder layers, plus integration tests for MNG-4379, MNG-4590, MNG-3586, and IT0085, each covering both the new default AND the opt-out path.

Two observations (non-blocking):

1. Configuration documentation gap (DefaultModelInterpolator.java): The maven.model.dependencyInterpolation.full opt-out property is declared as a local constant in two implementation classes (DefaultModelInterpolator and AbstractStringBasedModelInterpolator), unlike its companion maven.repository.dependencyManagement.allowSystemScope which is in Constants.java with @Config. This means Maven's auto-generated configuration docs will list one opt-out property but not the other — both change long-standing behavior and are equally user-facing. Consider promoting to Constants.java with @Config and sharing a single constant definition.

2. Future-proofing note (DefaultModelBuilder.java:640): The replace && isBuildRequest() guard in mergeRepositories is correct for today's RequestType values, but implicitly assigns recessive merging to any future non-build request type. A brief code comment noting this design choice would help future maintainers.

📋 PR Metadata

Aspect	Current	Suggested
Milestone	(none)	4.0.0

🔀 Backport Status

• ⏳ master — #12948 (OPEN)
• ⏳ maven-3.10.x — #12953 (OPEN)
• ℹ️ maven-3.9.x — not targeted (appropriate for behavior-changing enhancement)

---

_{🤖 This review was generated by ForgeBot.}

[gnodet]

Delta review — two new commits (same as master sibling #12948) address both previous observations:

1. ✅ Configuration documentation gap → Fixed. maven.model.dependencyInterpolation.full promoted to Constants.java with @Config(type = "java.lang.Boolean", defaultValue = "false"), @since 4.1.0, and comprehensive Javadoc. Compat duplicate made private with cross-reference comment.

2. ✅ Future-proofing note → Fixed. Design-intent comment added to mergeRepositories explaining that non-build RequestTypes intentionally fall through to recessive merging.

No new issues in the delta. Consistent with the already-approved master PR.

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