[Utkarsh-rwt]

Summary

Backport of the #13390 fix for Maven 3.10.x.

Dependency POM-local properties must not activate property-based profiles in the same POM during external model building. Maven 3.10.x currently merges POM properties into the external profile activation system-property lookup, which causes unintended profile activation.

Changes

• Stop merging dependency POM-local properties into external system properties.
• Preserve system-property, JDK, OS, and negated-property/default-on activation behavior.
• Continue suppressing consumer user properties for dependency POM profile activation.
• Update the 3.10.x compat regression test to assert that POM-local properties do not activate profiles.

Validation

• mvn -pl maven-model-builder -Dtest=ResolvedDependencyProfileActivationTest -Dsurefire.failIfNoSpecifiedTests=false test

• Result: 10 tests passed, 0 failures, 0 errors.

• I hereby declare that I have filed an Apache Individual Contributor License Agreement.

• I hereby declare this contribution to be licensed under the Apache License Version 2.0, January 2004

[gnodet]

LGTM. Mechanically correct fix: removing the getSystemProperties() merge of POM-declared properties means PropertyProfileActivator (which only consults user + system properties) can no longer see POM-local properties in external model builds. No residual leak path — no activator calls getProjectProperties() directly. The test rename and assertion inversion correctly validate the new behavior, and the static trace confirms the old assertEquals("activated", ...) would fail with the new code.

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

[Utkarsh-rwt]

After reviewing #13084/#13112/#13114, I believe the #13390 change should not be retained as currently implemented.

The external-model sandbox intentionally exposes dependency POM properties because they are part of the published model and are required for profiles such as RESTEasy’s defaults and BOM/dependency-management profiles. Removing that lookup or returning null from getModelProperty() would regress the behavior fixed by #13084.

I will withdraw the Maven 3.10.x backport and revert the #13390 changes unless maintainers confirm that the documented behavior should supersede the established #13084 design.

[Utkarsh-rwt]

@gnodet

[gnodet]

Fully automatic review from Claude Code

@Utkarsh-rwt Your instinct in the comment above was right to question the approach, but the concern about regressing #13084 turns out to be unfounded. The actual RESTEasy profile that motivated #13084 uses a negated-property pattern (!resteasy.dependencies.eap), not a positive POM-property activation — so removing the POM-property merge does not break it.

Replacement PRs with a complete fix, tests, and updated Javadoc have been submitted:

• Fix #13390: stop POM properties from self-activating profiles in external builds #13450 — master
• [3.10.x] Fix #13390: stop POM properties from self-activating profiles in external builds #13451 — maven-3.10.x backport (replaces this PR)
• [4.0.x] Fix #13390: stop POM properties from self-activating profiles in external builds #13452 — maven-4.0.x backport