[MNG-8287] Backport consumer POM packaging profile resolution to 4.0.x

[gnodet]

Summary

Backport of #12744 to the maven-4.0.x branch.

• Cherry-picked all 4 commits from the original PR
• Resolved merge conflicts (import statements, coexistence with active profile properties tests already on 4.0.x)
• Adapted testBomPackagingActivatedProfilesArePreserved to a pure unit test since bom packaging is not supported by the model builder on 4.0.x

Changes

Maven 4 introduces support for activating profiles based on the project's <packaging> type. However, when a dependency built with Maven 4 is consumed by tools such as Maven 3, Gradle, or IDEs that do not understand the <packaging> activation condition, dependency resolution can differ between tools.

This change updates consumer POM generation to resolve packaging-based profile activation before the consumer POM is published, ensuring that downstream consumers see a consistent and predictable set of dependencies.

Test plan

• All 16 ConsumerPomBuilderTest tests pass on 4.0.x
• CI passes

🤖 Generated with Claude Code

[gnodet]

✅ Looks Good

Clean backport of PR #12744 (MNG-8287) from master to maven-4.0.x. The consumer POM packaging profile inlining logic is correct, all activation model fields are accounted for, and the test adaptations for 4.0.x are appropriate.

Technical notes:

• The core inlining logic in inlinePackagingActivatedProfiles correctly handles all four profile scenarios: matching-only-packaging (inline and remove), matching-with-other-conditions (strip packaging, keep profile), non-matching (drop entirely), and no-packaging-activation (keep as-is). The deduplication strategy using putIfAbsent correctly gives model-level dependencies precedence over profile-declared duplicates.
• The stripPackagingActivation method covers all seven Activation model fields (activeByDefault, jdk, os, property, file, packaging, condition). The packaging field is correctly omitted from the emptiness check since it was already stripped to null.
• The BOM test adaptation to a pure unit test is a pragmatic choice since bom packaging is not supported by the model builder on 4.0.x. The test still validates that transformBom preserves packaging-activated profiles for child modules.
• On master, stripPackagingActivation delegates to a shared isActivationEmpty() method. The backport correctly inlines this check since isActivationEmpty does not exist on 4.0.x. The two implementations are logically equivalent.

Minor observation:

• ConsumerPomBuilderTest.java (lines ~432, 480-481): unnecessary escape of single quotes in double-quoted Java strings (\'1.0.0\' → '1.0.0'). Compiles correctly but appears to be a merge conflict resolution artifact.

📋 PR Metadata

Aspect	Current	Suggested
Labels	(none)	bug

🔀 Backport Status

• ⏳ master — #12744 (OPEN, original)
• ✅ maven-4.0.x — this PR
• ℹ️ Maven 3.x — not needed (packaging-based profile activation is a 4.x feature)

---

_{🤖 This review was generated by ForgeBot.}

[gnodet]

✅ Delta Review — New Commit Looks Good

New commit cb86a141 is a clean, focused fix that filters import-scoped managed dependencies (BOM imports) from inlined packaging-activated profiles before they leak into the consumer POM. Faithful backport of the equivalent upstream commit bf21878 on #12744.

Technical notes on the new commit:

• Correctly identifies that import-scoped entries in dependencyManagement are BOM-import directives that get flattened during resolution. Re-emitting them in the consumer POM would cause downstream consumers to redundantly re-import those BOMs.
• The "import".equals(dep.getScope()) pattern is null-safe (calling equals on the literal).
• The new test testImportScopedManagedDepsAreFilteredFromInlinedProfiles is thorough: sets up both an import-scoped BOM entry and a regular managed dependency, verifies the profile is inlined (removed), and asserts only the regular dependency survives.

Minor observation (cosmetic): After removeIf filters import-scoped entries, the additionalManagedDeps list could become empty (if all managed deps were import-scoped). In that scenario an empty <dependencyManagement/> element could be introduced. Extremely unlikely in practice.

Previous finding (unnecessary quote escaping in test strings) still applies.

---

_{🤖 This review was generated by ForgeBot.}

[github-actions]

@gnodet Please assign appropriate label to PR according to the type of change.