When two imported BOMs manage the same artifact, Maven uses the first import declared. In a multi-team build, that means whoever edits the import order can change a version for everyone. Document the order, review changes to it, and verify the resolved version with the dependency tree.
What a BOM import does
A bill of materials in Maven is a POM that lists managed dependency versions. A project imports it with scope import and type pom inside its dependency management section. The Maven documentation says importing brings in the managed dependencies from that POM.
The documentation also describes what happens when imports overlap. Its example has two imported POMs that both manage the same artifact, and the artifact resolves to the version from the one declared first.
Why this becomes a team dispute
Many organizations keep a company BOM from a platform team, plus a framework BOM, plus a BOM from a shared internal library. Two of them often manage the same artifact at different versions.
Now a security fix is needed. The platform team says the company BOM sets the version. The service team says the framework BOM does. In reality, the answer is whichever comes first in the import list, and nobody may have chosen that on purpose.
Precedence in one table
The Maven guide gives these rules for managed versions.
| Rule | Effect |
|---|---|
| The current POM's declaration beats its parent's | A child can override a parent's managed version |
| Dependency management beats mediation for transitive dependencies | Managed version wins even if a deeper path asks for another |
| Among imports, first declared wins | Order in the file matters |
One more point from the guide: dependency management does not affect the transitive dependencies of plugins. A fix in the managed section will not reach a plugin's own dependencies.
How to settle it
- Find the real answer. Run the dependency tree and check which version resolved, and from which management section.
- Pick an owner for order. Treat the import list like an API. A platform team owns the order in the parent POM, and changes need their review.
- Override locally when needed. The guide says the current POM's declaration beats its parent's, so a service can set its own managed version for a security fix. Confirm in the dependency tree that it took effect, and add a comment with the advisory and an expiry.
- Raise it upstream. If a shared BOM manages a vulnerable version, open an issue or PR with the BOM owner so every consumer benefits.
A review checklist for BOM changes
- Does the change alter the order of imports?
- Does a newly added BOM manage any artifact that another import already manages?
- Did the resolved versions change? Compare the tree before and after.
- Do the affected services still pass tests?
A before and after dependency tree diff in the PR takes a minute and prevents most surprises.
Quick check
Which BOM wins if two manage the same artifact?
The one imported first in the dependency management section, according to the Maven dependency mechanism guide.
Can a service override a version set by an imported BOM?
Usually. The guide says the current POM's declaration takes precedence over its parent's. Confirm the result in the dependency tree and record the reason.
Sources
Last reviewed: 19 October 2026.
