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 and reports a model id,
while a POM handed to Maven as a file reports none. MavenITmng4765LocalPomProjectBuilderTest covers
the latter, and two unit tests assert a caller-supplied model is left alone. Keying on the request type
alone would not work: a POM supplied through the 2.x project builder API arrives with the same type as a
resolved dependency.

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. This is the master sibling of #12943 (maven-4.0.x), carrying the same logic with consistent implementations across compat and impl paths.

The test coverage is excellent: unit tests cover profile activation filtering, interpolation restriction, cache partitioning, externalOrigin propagation through grandparent hops, caller-supplied model exemption, and the opt-out property; integration tests cover both the new default and the opt-out for MNG-4379, MNG-4590, and MNG-3586.

Two observations (non-blocking, same as 4.0.x review):

1. Configuration documentation gap (DefaultModelInterpolator.java:67): The maven.model.dependencyInterpolation.full opt-out property is declared as a local constant in two implementation classes, unlike its companion maven.repository.dependencyManagement.allowSystemScope which is in Constants.java with @Config. This means it won't appear in Maven's generated configuration documentation, creating a discoverability gap for users who need the opt-out. Since this PR changes longstanding default behavior (env-var interpolation in repository-resolved POMs, active since MNG-4379 in 2009), the opt-out should be as discoverable as possible.

2. Future-proofing note (DefaultModelBuilder.java:645): The replace && isBuildRequest() guard in mergeRepositories is correct for all current request types, but any future non-BUILD request type will implicitly receive recessive merging without an explicit decision. A brief code comment noting this design intent would help future maintainers.

Technical notes:

• The compat and impl implementations are consistent: isSafeExternalExpression is identical; compat correctly omits condition activation filtering (doesn't exist in legacy model builder).
• externalOrigin propagation through derive() is correctly sticky — a dependency's parent inherits the restriction.
• The ModelSource.getModelId() != null approach is cleaner than modifying request type classification, and preserves full interpolation for the 2.x project builder API path.

📋 PR Metadata

Aspect	Current	Suggested
Milestone	(none)	4.1.0

🔀 Backport Status

• ✅ maven-4.0.x — #12943 (OPEN, reviewed)
• ⏳ 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 since the previous review address both observations:

1. ✅ Configuration documentation gap → Fixed. maven.model.dependencyInterpolation.full is now promoted to Constants.java with @Config(type = "java.lang.Boolean", defaultValue = "false"), @since 4.1.0, and comprehensive Javadoc. The compat module's duplicate is correctly made private with a cross-reference comment explaining why it can't import from maven-api-core. Tests updated to use Constants.MAVEN_MODEL_DEPENDENCY_INTERPOLATION_FULL.

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

Both observations from the previous review are resolved. No new issues in the delta.

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