skip to content

When would you author a BOM versus using a parent POM to share versions?

level: seniorimportance: should knowfreq 55%

answer

  1. parent = build config, single parent
  2. BOM = versions only, import many
  3. external consumers -> BOM
  4. spring: starter-parent vs dependencies
  5. parent inherits plugins/props

basics

~20 s

Use a parent POM to share build config, plugins, and properties across YOUR modules (single parent only). Use a BOM when you want to publish version-only management that EXTERNAL consumers import, possibly alongside their own parent.

solid answer

~40 s

A parent POM shares more than versions: plugin management, properties, profiles, reporting, and dependencyManagement — but Maven allows only one parent, and inheritance is internal to your reactor. A BOM shares only `<dependencyManagement>` and is consumed via `<scope>import</scope>`, so consumers can import several BOMs and keep their own parent. In a multi-module project you typically have a parent for internal build governance; you publish a separate BOM (often it can be the same aggregator or a dedicated module) so downstream teams pin your module versions without adopting your parent. Rule of thumb: parent = build configuration for projects you own; BOM = version contract for projects you don't.

go deeper

for a junior

Know parent shares lots of config; BOM shares only versions.

for a middle

Explain single-parent limit and multi-import of BOMs.

for a senior

Choose the right tool per audience; ship both like Spring Boot when appropriate.

for a principal

Design org library distribution: parent for internal reactor, BOM as the external version contract.

## Two different problems Both a parent POM and a BOM can carry a `<dependencyManagement>` section, which causes confusion. The difference is **what else they do** and **how they are consumed**. ## Parent POM A child declares a `<parent>` and inherits: - `<dependencyManagement>` and `<dependencies>` - `<pluginManagement>` and `<build>` config - `<properties>`, `<profiles>`, `<reporting>`, distribution/SCM info, etc. Constraints: - **Exactly one parent** per project (single inheritance). - Inheritance is the natural mechanism for a multi-module **reactor** — your own modules. - Consumers who adopt your parent inherit your *whole* build opinion (plugins, encoding, Java version) — usually unwanted for external libraries. ```xml <parent> <groupId>com.acme</groupId> <artifactId>acme-parent</artifactId> <version>1.4.0</version> </parent> ``` ## BOM A BOM carries **only** managed versions and is consumed by **import**, not inheritance: - A consumer can import **many** BOMs. - It brings **no** plugins, properties, or build config — purely a version catalog. - It is the right tool for publishing a version contract to teams who already have their own parent. ## Decision guide | Need | Use | |---|---| | Share plugins/encoding/Java version across modules you own | Parent | | Publish only versions for external consumers | BOM | | Consumer already has a parent | BOM (import) | | Combine several upstream version sets | Multiple BOM imports | | One coherent internal multi-module build | Parent (and optionally also ship a BOM) | ## Common real-world pattern Spring Boot ships **both**: `spring-boot-starter-parent` (a parent that pre-configures plugins) **and** `spring-boot-dependencies` (a pure BOM). Teams that want full opinionation use the parent; teams with their own corporate parent import the BOM instead. Authoring your own library? Do the same: an internal parent for your reactor, plus a published BOM so downstream users pin your modules without inheriting your build.

  • Can a project use both a parent POM and an imported BOM?
    Yes — common. You have one parent for build config and import one or more BOMs for additional managed versions.
  • Why does Spring Boot publish both a parent and a BOM?
    The parent adds plugin config and opinions; the BOM lets teams with their own parent still get Spring's curated versions via import.

A parent POM is like joining a franchise: you adopt the whole operating manual. A BOM is like a recommended-suppliers list you can use no matter who you franchise with.

saying these in an interview costs you the question

  • Claiming you can have multiple parents.
  • Saying a BOM brings plugin/build configuration (it only manages versions).
  • Forcing external consumers to adopt your parent just to get versions.

context

resolving links…