Fix #13084: sandbox profile activation context for external model builds

[gnodet]

Backport of #13112 (master) and #13114 (maven-3.10.x) to maven-4.0.x.

Instead of blanket-filtering file and property profiles in external model builds (dependency POMs, parent POMs, imported BOMs), evaluate them against a sandboxed ProfileActivationContext that:

• Merges model <properties> into system property lookups — POM-declared properties drive activation in dependency builds.
• Suppresses user properties — consumer -D flags must not activate dependency profiles.
• Pre-filters file-activated profiles (returning false from exists() would incorrectly activate <missing> profiles).
• Strips repository contributions from active external profiles.

Both compat and impl stacks updated identically. Tests cover all activation paths including the system-property opt-out of default-on profiles.

[gnodet-bot]

Two findings on the sandbox implementation.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[gnodet-bot]

test

[gnodet-bot]

test

[gnodet-bot]

test

[gnodet-bot]

test

[gnodet-bot]

test

[gnodet-bot]

test

[gnodet-bot]

Two issues in the sandbox implementation worth fixing before merge.

---

Finding 1 — Mutable map leak in compat externalActivationContext (inline below)

See inline comment on compat/maven-model-builder/.../DefaultModelBuilder.java line 550.

---

Finding 2 — Condition profiles using missing(path) incorrectly activate in the external-model sandbox

The pre-filter in impl/maven-impl/.../DefaultModelBuilder.java (around the nonFileProfiles stream) only drops profiles whose activation.file != null. Condition profiles whose expression calls missing(…) pass through unchanged. Inside the sandbox context.exists() always returns false, so missing(path) evaluates to !false = true — the profile fires regardless of whether the publisher's path actually exists on the consumer machine. This is the same <missing>-flips-to-active footgun the pre-filter was introduced to prevent for <activation><file>, now re-exposed for condition expressions.

Before this PR, hasFileOrPropertyOrConditionActivation excluded all condition profiles from external models (the same helper is still used today in the BUILD_CONSUMER path). That protection was removed for CONSUMER_DEPENDENCY when the sandbox replaced the hard filter. No test covers a condition profile with exists()/missing() against a CONSUMER_DEPENDENCY build.

Suggested fix — extend the pre-filter:

private static boolean hasFileConditionExpression(Profile p) {
    Activation a = p.getActivation();
    if (a == null || a.getCondition() == null) return false;
    String c = a.getCondition();
    return c.contains("exists(") || c.contains("missing(");
}

Then change the filter from:

.filter(p -> p.getActivation() == null
        || p.getActivation().getFile() == null)

to:

.filter(p -> p.getActivation() == null
        || (p.getActivation().getFile() == null
                && !hasFileConditionExpression(p)))

A test asserting that a missing('/publisher/private/file') condition profile does not activate in a CONSUMER_DEPENDENCY build is required.

This review was generated by an AI agent, Hermès on behalf of @gnodet.

[gnodet-bot]

Re-review after f321eab98f. Both prior findings addressed:

Finding 1 (mutable map leak in compat sandbox) — Fixed. The empty-projectProps branch now wraps delegate.getSystemProperties() with Collections.unmodifiableMap() (compat DefaultModelBuilder.java line 548). The non-empty branch was already defensive; both branches are now consistent.

Finding 2 (missing()-condition profiles activate unconditionally in sandbox) — Fixed. hasFileConditionExpression() helper added in impl DefaultModelBuilder, pre-filters condition profiles whose expression contains exists( or missing( before they reach the sandbox. The test in resolved-model-with-profiles.xml + DefaultModelBuilderTest.testDependencyModelActivatesOnlyEnvironmentIndependentProfiles confirms suppression in CONSUMER_DEPENDENCY and that the profile still fires in a project build (where the path genuinely doesn't exist).

I verified that the compat stack's withoutFileActivation not filtering condition profiles is a non-issue: maven-model-builder has no ConditionProfileActivator — condition activation is impl-only. The hasFileConditionExpression string heuristic (contains("exists(") / contains("missing(")) can only produce false positives (conservative: drop a legitimate profile), never false negatives. The design choice that POM-declared property profiles activate in external builds but not project builds is explicitly asserted and documented.

Clear to merge.

This review was generated by an AI agent, Hermès on behalf of @gnodet.