[MNG-5146] Fix parent relativePath mismatch check - #13157
Conversation
* Fix parent relativePath mismatch check * Address review: keep GA check, downgrade to WARNING when relativePath is null * Add tests for MNG-5146: GA mismatch WARNING vs FATAL per relativePath presence * Address review: use assertFalse instead of assertTrue(!expr) * Address review: use maven3Personality instead of modelVersion guard, improve mismatch messages - impl/DefaultModelBuilder: replace MODEL_VERSION_4_0_0 equality check in mismatchRelativePathAndGA() with Features.mavenMaven3Personality(). The modelVersion was used as a proxy for 'tolerate legacy mismatches', but the correct abstraction is the maven3Personality flag. FATAL is now emitted when relativePath is explicit AND maven3Personality is off; WARNING in all other cases (default path, or maven3 compat mode). - Both layers: separate message text for the two cases so the user knows whether Maven probed the default location on its own, or their explicit <relativePath> points at the wrong artifact, with actionable fix hints. - compat/DefaultModelBuilder: keep WARNING in both cases (compat layer is always Maven 3 territory; no FATAL escalation). Rename test to testParentGaMismatchExplicitRelativePathProducesWarning accordingly. * fix: use parent parameter directly and update IT assertion to match new message format * Address review: simplify message construction with local variables --------- Co-authored-by: Guillaume Nodet <gnodet@gmail.com>
gnodet-bot
left a comment
There was a problem hiding this comment.
Clean backport. Verified the following:
Behavioral correctness of the warn condition change:
The old impl condition (MODEL_VERSION_4_0_0.equals(childModel.getModelVersion()) || relativePath == null) has been replaced by defaultPath || maven3Mode. This is semantically tighter: Maven 3 POMs (model 4.0.0) with an explicit wrong <relativePath> no longer get a courtesy WARNING in Maven 4 non-compat mode — they get FATAL. That's the right call; explicit misconfiguration is a hard error in Maven 4. The --maven3Personality escape hatch preserves backward compat.
Compat layer parent.getRelativePath() == null check:
The compat getParentPomFile() already substitutes "../pom.xml" when getRelativePath() is null, so by the time readParentLocally() calls into the mismatch block, null unambiguously means "Maven probed the default location." The new message is accurate in all reachable code paths.
Call site coverage on maven-4.0.x:
The base branch has exactly two call sites for mismatchRelativePathAndGA — both have been updated. The third call site that exists on master (in ParentResolutionFrame.advance()) is not present in maven-4.0.x, so no missed update.
IT assertion update (MavenITmng8294ParentChecksTest):
The bad-mismatch child POM uses explicit <relativePath>..</relativePath> and namespace 4.1.0 (Maven 4 mode, no maven3Personality), so the FATAL path triggers. The updated log text "which resolves to ... instead of the declared parent ..." correctly matches the new message template.
Tests:
Both compat unit tests exercise the right scenarios. testParentGaMismatchDefaultRelativePathProducesWarning sets no <relativePath> in the child POM (null → WARNING); testParentGaMismatchExplicitRelativePathProducesWarning uses <relativePath>../pom.xml</relativePath> (non-null → WARNING in compat, which always stays lenient). Assertions are specific and meaningful.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
Backport of #13086 to
maven-4.0.x.Cherry-pick of 4309183, resolved one conflict in
impl/maven-implDefaultModelBuilder: call sites updated to the newmismatchRelativePathAndGA(childModel, parent, groupId, artifactId)signature.