Managing Dependency Versions & Conflicts

Introduction

Across the last 24 lessons, you added dozens of Spring Boot starters and almost never wrote a version number. That is not an accident — it is one of Spring Boot's most valuable, least visible features. This lesson pulls back the curtain on how it works, and what to do the rare times it does not.

Why This Lesson Matters

Every starter used throughout this course — web, data JPA, security, mail, Kafka, Quartz, and more — was added without a <version> tag, and every one of them just worked together. That consistency comes from a curated, tested set of versions maintained by the Spring Boot team, and understanding how you plug into that set is what turns you from someone who copies dependency snippets into someone who can actually debug a broken build.

spring-boot-starter-parent

Most Spring Boot projects declare spring-boot-starter-parent as their Maven <parent>. It supplies default versions for hundreds of common dependencies (including every Spring Boot starter), sensible plugin defaults, and a default Java version — all inherited automatically.

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.3.4</version>
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
        <!-- no <version> needed - inherited from the parent -->
    </dependency>
</dependencies>

The BOM Alternative: spring-boot-dependencies

Sometimes your project already has a different required parent POM (for example, a company-wide corporate parent) and cannot also inherit from spring-boot-starter-parent — Maven only allows one <parent>. In that case, import spring-boot-dependencies as a Bill of Materials (BOM) inside <dependencyManagement> instead. This gives you the exact same version-management benefit without requiring it to be your parent.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>3.3.4</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Inspecting the Dependency Tree

Every starter pulls in transitive dependencies of its own, and those can overlap or conflict across starters. Before assuming a version problem, always look at what Maven or Gradle actually resolved.

mvn dependency:tree

gradle dependencies

Resolving a Version Conflict with Exclusions

Occasionally a third-party library you add pulls in an older or conflicting transitive version of something Spring Boot already manages (a classic example: an older logging library pulling in a conflicting SLF4J binding). The fix is an <exclusion> — tell Maven to skip that specific transitive dependency, then let the version supplied by spring-boot-starter-parent (or the BOM) win instead.

<dependency>
    <groupId>com.some-vendor</groupId>
    <artifactId>some-legacy-sdk</artifactId>
    <version>1.8.0</version>
    <exclusions>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Common Mistakes

Best Practices

Frequently Asked Questions

Summary

spring-boot-starter-parent (or the spring-boot-dependencies BOM when you cannot use it as your parent) is why you have not needed to specify a version number across this entire course. When something does conflict, dependency:tree shows you the truth, and <exclusion> lets you fix it precisely.