Skip to content

Fix mvnup: use effective model to resolve properties from remote parents#12158

Open
gnodet wants to merge 1 commit into
masterfrom
mulberry-motion
Open

Fix mvnup: use effective model to resolve properties from remote parents#12158
gnodet wants to merge 1 commit into
masterfrom
mulberry-motion

Conversation

@gnodet
Copy link
Copy Markdown
Contributor

@gnodet gnodet commented May 26, 2026

Summary

  • Fix CompatibilityFixStrategy incorrectly commenting out dependencyManagement entries whose versions use properties inherited from remote parent POMs (e.g., ${oak.version} from sling-parent, ${version} from a published parent)
  • The existing static analysis only scanned reactor POMs for property definitions, missing properties from remote parents
  • Now uses the buildEffectiveModel infrastructure (already available in AbstractUpgradeStrategy) to resolve properties from the full parent chain before deciding a property is "undefined"

Fixes gnodet/maven4-testing#13383
Fixes gnodet/maven4-testing#13374

Test plan

  • New test: property from external parent not in reactor is correctly recognized as defined
  • New test: truly undefined property (not in any parent) is still correctly commented out
  • All 24 existing CompatibilityFixStrategyTest tests continue to pass

🤖 Generated with Claude Code

…mvnup

The undefined property detection in CompatibilityFixStrategy only performed
static analysis of reactor POMs, missing properties inherited from remote
parent POMs. This caused valid dependencyManagement entries to be incorrectly
commented out, breaking child modules relying on them for version resolution.

Now uses buildEffectiveModel to collect properties from the full parent chain,
including remote parents resolved via relativePath or Maven repositories.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant