skip to content

The dependency BOM

Importing spring-boot-dependencies as a BOM gives you Boot's managed versions without inheriting its parent, in either Maven or Gradle. The usual answer to the parent-POM conflict question.

part ofSpring Frameworkoverview, primer and where to startread it →
on this pageshow

questions

5

What is the spring-boot-dependencies BOM and what problem does it solve?

level: juniorimportance: must knowfreq 70%

answer

  1. packaging=pom, only dependencyManagement
  2. curated, tested-together versions
  3. declare starters with no version
  4. version == Boot version
  5. manages versions, adds nothing

basics

~10 s

spring-boot-dependencies is a BOM (Bill of Materials): a special POM listing tested, compatible versions of Spring and third-party libraries. Import it so you declare dependencies without versions and get a consistent, curated version set.

solid answer

~40 s

The spring-boot-dependencies BOM is a Maven POM of packaging type 'pom' that contains a large <dependencyManagement> section pinning versions for hundreds of libraries Spring Boot tests together (Spring modules, Jackson, Hibernate, Tomcat, Kotlin, etc.). By importing it, your build inherits those managed versions, so you declare dependencies like spring-boot-starter-web with no <version> element. The BOM only manages versions, it doesn't add any dependencies to your build. The benefit is a single curated, mutually-compatible dependency set that eliminates version guesswork and reduces conflicts. Its version equals the Spring Boot version you target. It is the same version data the spring-boot-starter-parent uses under the hood, but importing the BOM directly lets you use it without inheriting the Boot parent POM.

code

kotlin · 17 lines
kotlin
// Excerpt of what spring-boot-dependencies conceptually contains (Maven POM view):
// <dependencyManagement>
//   <dependencies>
//     <dependency>
//       <groupId>com.fasterxml.jackson.core</groupId>
//       <artifactId>jackson-databind</artifactId>
//       <version>2.17.2</version>
//     </dependency>
//     ... hundreds more ...
//   </dependencies>
// </dependencyManagement>
//
// Result in your build.gradle.kts (versions omitted, resolved from BOM):
dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web")
    implementation("com.fasterxml.jackson.module:jackson-module-kotlin")
}

go deeper

for a junior

Know it's a curated list of compatible versions letting you omit versions on starters.

for a middle

Explain packaging=pom, dependencyManagement-only, and that it adds nothing.

for a senior

Contrast parent-inheritance vs direct import and note version-override precedence.

for a principal

Frame it as the reproducible, tested dependency contract and its role in supply-chain/version governance.

## What a BOM is A **BOM (Bill of Materials)** is a normal Maven POM whose `<packaging>` is `pom` and whose main purpose is a large `<dependencyManagement>` block. `<dependencyManagement>` does **not** add dependencies to a project — it only declares *what version to use* if and when a given dependency is requested. Think of it as a lookup table: 'if anyone asks for `com.fasterxml.jackson.core:jackson-databind`, use version X'. ## spring-boot-dependencies specifically `org.springframework.boot:spring-boot-dependencies` is the BOM Spring Boot publishes. Its version string equals the Spring Boot release you target (e.g. `3.3.4`). Inside it are managed versions for: - Every Spring Boot and Spring Framework module (spring-core, spring-web, spring-context, all the `spring-boot-starter-*` artifacts). - Hundreds of third-party libraries Spring Boot integrates with and **tests together**: Jackson, Hibernate/JPA, Tomcat/Jetty/Undertow, Netty, Micrometer, Logback/SLF4J, Kotlin, JUnit, Mockito, Testcontainers, and so on. Because Spring engineers run integration tests against this exact combination, the versions are known to be mutually compatible. That is the core value: you don't hand-pick versions and risk `NoSuchMethodError` from a Jackson/Hibernate mismatch. ## How you consume it When the BOM's managed versions are in effect, you write dependencies **without a version**: ```xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> <!-- no <version> --> </dependency> ``` Maven resolves the version from dependency management. There are two ways to bring the BOM in: 1. **Inherit `spring-boot-starter-parent`** — the parent POM itself imports spring-boot-dependencies, plus adds plugin config, resource filtering, Java version, etc. 2. **Import the BOM directly** with `<scope>import</scope>` — gives you only the version management, no parent inheritance. Useful when your project already has another parent (a corporate parent POM) since Maven allows only one parent. ## Key gotchas - Importing the BOM adds **zero** dependencies — you still declare each starter you want; it only supplies versions. - The BOM version must match the Spring Boot version you actually use; mixing a `3.3.x` BOM with `3.4.x` starters is unsupported. - A `<dependency>` version you write explicitly always wins over the BOM's managed version (nearest/explicit wins), which is how you override. ## When to use Always, for any Spring Boot project. Use the parent for greenfield apps; use the import scope when you can't inherit the Boot parent.

  • Does importing the BOM add spring-boot-starter-web to your classpath?
    No. A BOM only supplies managed versions via dependencyManagement. You still declare each dependency yourself; the BOM just fills in the version.
  • What version should the spring-boot-dependencies BOM be?
    The same as the Spring Boot version you target — the BOM is versioned in lockstep with each Boot release, e.g. 3.3.4.

saying these in an interview costs you the question

  • Saying the BOM downloads/adds dependencies by itself.
  • Thinking you must still specify versions on starters after importing it.
  • Believing you need the Boot parent POM to get managed versions.

context

open as a page

In Maven, how do you use the Spring Boot managed versions without inheriting spring-boot-starter-parent?

level: middleimportance: must knowfreq 65%

basics

~10 s

Import the BOM in <dependencyManagement> with type 'pom' and <scope>import</scope>. That pulls in spring-boot-dependencies' managed versions without making the Boot parent your project's parent.

open as a page

In Gradle, what are the two ways to consume the Spring Boot BOM, and how do they differ?

level: seniorimportance: should knowfreq 55%

basics

~10 s

Either use Gradle's native platform() (e.g. implementation(platform("org.springframework.boot:spring-boot-dependencies:3.3.4"))) or apply the io.spring.dependency-management plugin. platform() is Gradle-native; the plugin mimics Maven-style dependency management.

open as a page

How do you override a version that the Spring Boot BOM manages, and what are the risks?

level: seniorimportance: should knowfreq 50%

basics

~10 s

With the Boot parent, override the documented version property (e.g. <jackson-bom.version>). With Gradle plugin, set the matching ext property. Or declare an explicit version on the dependency. The risk: you break the tested-compatible set.

open as a page

In a multi-module build importing several BOMs, how do version conflicts resolve, and how would you govern this across an organization?

level: principalimportance: nice to knowfreq 30%

basics

~20 s

When multiple BOMs manage the same artifact, Maven picks the first-declared entry (first-wins), while Gradle merges constraints and resolves to the highest compatible unless enforced. Govern with a single company platform/BOM module that all projects import.

open as a page