gnodet commented on PR #12417:
URL: https://github.com/apache/maven/pull/12417#issuecomment-4933683715
Thanks for working on this @Hiteshsai007. The pain point is real and
well-documented (the SO thread has 10k+ views), so I understand the motivation.
However, I don't think extending BOM imports to include properties is the
right approach. Here are the concerns:
### Property pollution
A typical BOM (Spring Boot, Quarkus) defines **hundreds** of properties —
`maven.compiler.source`, `project.build.sourceEncoding`, internal version
properties, plugin versions, etc. Enabling this feature dumps *all* of them
into the consuming project's property space. There's no way to selectively
import only the properties you need.
### Silent semantic drift
Even with opt-in, enabling this once means *every* BOM import in the project
starts leaking properties. Adding or removing a BOM — or reordering BOM
declarations — becomes a much riskier operation, as it can silently change
compiler settings, plugin versions, encoding, etc.
### Multi-BOM ordering fragility
With multiple BOMs, property conflicts are resolved by declaration order
(first wins). Reordering `<dependency>` entries in `<dependencyManagement>` —
normally harmless — can now change the build's behavior.
### Blurs the parent/BOM distinction
Maven's model has a clear separation: **parents** provide inheritance
(properties, plugins, settings), **BOMs** provide dependency management. This
erodes that boundary.
### Mixins as the proper solution
Maven 4 already has **mixins** (4.2.0+) which are designed for exactly this
use case. They already:
- Explicitly inherit properties (with proper precedence semantics)
- Inherit the full model through the standard `inheritanceAssembler`
- Are declared explicitly — the user chooses exactly which POMs to mix in
- Have clear, well-defined semantics
The scenario from MNG-8432 would be solved cleanly with:
```xml
<mixins>
<mixin>
<groupId>com.company</groupId>
<artifactId>company-bom</artifactId>
<version>1.0.0</version>
</mixin>
</mixins>
```
This gives both the dependency management **and** the properties, without
silently pulling in properties from every BOM in the dependency management
section.
I think the right path forward is to point users toward mixins rather than
overloading `<scope>import</scope>` semantics. If you're interested in
contributing, improving mixin documentation or writing integration tests for
the mixin-properties use case would be very valuable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
