Skip to content

Conversation

gnodet
Copy link
Contributor

@gnodet gnodet commented Sep 17, 2025

Summary

Fixes MNG-11133 where mixin properties were not overriding properties inherited from the parent.

Problem

Mixins are applied after parent inheritance, but the merge was using sourceDominant=false, causing the existing model's properties to win over the mixin's properties. This meant that parent properties would override mixin properties, which is incorrect behavior.

For example:

  • Parent defines maven.compiler.release=11
  • Mixin defines maven.compiler.release=21
  • Expected: effective property should be 21 (mixin wins)
  • Actual: effective property was 11 (parent wins)

Solution

  • Add package-private overload in DefaultInheritanceAssembler to control source dominance during model inheritance
  • Use sourceDominant=true when applying mixins so mixin properties override previously inherited ones
  • Apply the same fix for mixins applied to parent models when building subprojects
  • Add integration test to reproduce and verify the fix

Changes

Core Changes

  1. DefaultInheritanceAssembler.java: Added package-private overload with sourceDominant parameter
  2. DefaultModelBuilder.java: Use sourceDominant=true when applying mixins in two places:
    • Main mixin application (line ~1195)
    • Mixin application to parent models when building subprojects (line ~1633)

Test Changes

  1. MavenITmng11133MixinsPrecedenceTest.java: New integration test that:
    • Creates a parent with maven.compiler.release=11
    • Creates a mixin with maven.compiler.release=21
    • Creates a project using both parent and mixin
    • Asserts that the effective property is 21 (mixin wins)

Testing

The integration test should fail before the fix and pass after the fix, confirming that the bug is reproduced and resolved.

Backward Compatibility

This change corrects the behavior to match the expected semantics of mixins. While it changes the effective property values in some cases, it aligns with the documented and expected behavior that mixins should override parent properties.


Note: This is a draft PR. The integration test may need the full Maven build to run properly due to dependencies on IT support modules.


Pull Request opened by Augment Code with guidance from the PR author

Mixins are applied after parent inheritance, but the merge was using
sourceDominant=false, causing the existing model's properties to win
over the mixin's properties. This meant that parent properties would
override mixin properties, which is incorrect behavior.

Changes:
- Add package-private overload in DefaultInheritanceAssembler to control
  source dominance during model inheritance
- Use sourceDominant=true when applying mixins so mixin properties
  override previously inherited ones
- Apply the same fix for mixins applied to parent models when building
  subprojects
- Add integration test to reproduce and verify the fix

The fix ensures that mixins behave as expected: properties defined in
mixins override those inherited from the parent, maintaining the
correct precedence order.
The integration test was failing in CI because it depended on maven-it-plugin-expression
which is not available in the CI environment. Updated the test to use help:effective-pom
instead, which is a standard Maven plugin that's always available.

The test still validates that mixin properties override parent properties by checking
that maven.compiler.release=21 (from mixin) instead of maven.compiler.release=11 (from parent)
in the effective POM.
Applied spotless formatting to MavenITmng11133MixinsPrecedenceTest.java:
- Fixed license header indentation
- Reordered imports (static imports last)
- Removed trailing blank line
Applied manual formatting fixes to XML files:
- Consolidated project element attributes to single line
- Removed extra blank lines
- Fixed trailing whitespace

These files are not covered by spotless configuration but need
to follow the same formatting standards for CI to pass.
The integration test XML file was missing a newline at the end,
causing spotless:check to fail. Added the required newline to
make the file compliant with formatting standards.
The test was using verifier.loadFile() which returns List<String> but assigning it to a String variable. Changed to use Files.readString() to read the file content as a String, which matches the expected variable type.

This fixes the compilation error:
incompatible types: java.lang.String cannot be converted to java.io.File
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mixins - Property Handling / Precendence
1 participant