Duplicating managed version

Introduction

In large enterprise applications, dependency management is one of the most critical yet error-prone aspects of software development. Modern build tools such as Maven and Gradle provide powerful mechanisms to manage dependency versions centrally. However, many software engineers frequently encounter a confusing and frustrating issue commonly referred to as Duplicating managed version.

The keyword Duplicating managed version typically appears as a build warning or error when the same dependency version is defined multiple times in a managed context. While the build may still succeed in some cases, ignoring this issue can lead to unpredictable runtime behavior, dependency conflicts, security vulnerabilities, and long-term maintenance problems.

This post is written for software engineers working in real-world company projects. It explains the root cause of the Duplicating managed version problem, demonstrates how to reproduce it, and provides multiple production-ready solutions with complete, executable example code. The goal is to help you fix the issue correctly and permanently, not just silence the warning.

What Does “Duplicating Managed Version” Mean?

Duplicating managed version occurs when a dependency version is defined more than once in a dependency management scope. This typically happens in the following scenarios:

• The same dependency is declared in multiple <dependencyManagement> sections across parent and child projects
• A dependency version is defined both in <dependencyManagement> and again directly in <dependencies>
• Multiple BOMs (Bill of Materials) manage the same dependency
• Version properties are overridden inconsistently

In Maven, this usually produces warnings like:
Duplicating managed version for org.springframework:spring-core

Even if the build passes, this warning indicates a design flaw in dependency management.

Why Should Care

In enterprise environments, dependency duplication is not a cosmetic issue. It can cause:

• Hidden version overrides
• Inconsistent builds across environments
• Hard-to-trace production bugs
• Security patch failures
• CI/CD pipeline instability

Ignoring the Duplicating managed version warning is equivalent to ignoring a compiler warning in production code.

Root Cause of Duplicating Managed Version

The root cause always boils down to multiple sources attempting to control the same dependency version.

Common root causes include:

• Parent POM and child POM both manage the same dependency
• Imported BOM already manages a dependency that is manually managed again
• Multiple parent POMs (directly or transitively) manage the same artifact
• Copy-paste configuration without understanding inheritance

Let us understand this through a reproducible example.

How to Reproduce the Duplicating Managed Version Issue

The following example uses Maven, as this issue is most commonly observed in Maven-based enterprise projects.

Step 1: Create the Parent POM

This parent POM manages a dependency version.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.company.platform</groupId>
    <artifactId>parent-project</artifactId>
    <version>1.0.0</version>
    <packaging>pom</packaging>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>5.3.30</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

</project>

Step 2: Create the Child Project

Now the child project again defines the same managed dependency version.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>com.company.platform</groupId>
        <artifactId>parent-project</artifactId>
        <version>1.0.0</version>
    </parent>

    <artifactId>child-service</artifactId>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>5.3.30</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
        </dependency>
    </dependencies>

</project>

Step 3: Build the Project

Run the following command:

mvn clean install

You will see a warning similar to:

Duplicating managed version org.springframework:spring-context:5.3.30

This is the classic Duplicating managed version problem.

Solution 1: Centralize Dependency Management in the Parent POM

The most recommended and cleanest solution is to manage each dependency version in exactly one place. In enterprise projects, that place should be the parent POM.

Corrected Child POM

Remove the <dependencyManagement> section entirely from the child.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                             http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>com.company.platform</groupId>
        <artifactId>parent-project</artifactId>
        <version>1.0.0</version>
    </parent>

    <artifactId>child-service</artifactId>

    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
        </dependency>
    </dependencies>

</project>

Solution 2: Use a BOM Correctly Without Redefining Versions

Many teams import Spring Boot or other BOMs and then accidentally redefine versions. Let the BOM manage versions entirely to avoid duplication.

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

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-context</artifactId>
    </dependency>
</dependencies>

Solution 3: Override Versions Using Properties (Advanced and Controlled)

In rare cases, enterprises need controlled overrides. Use properties but define them once.

<properties>
    <spring.context.version>5.3.30</spring.context.version>
</properties>

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${spring.context.version}</version>
        </dependency>
    </dependencies>
</dependencyManagement>

Solution 4: Remove Redundant Direct Dependency Versions

Another common mistake is defining versions in both places.

Incorrect:

<dependencyManagement>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.13.0</version>
    </dependency>
</dependencyManagement>

<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.13.0</version>
    </dependency>
</dependencies>

Correct: Remove the version from <dependencies>.

Best Practices to Avoid Duplicating Managed Version in Company Projects

• Manage every dependency version in one and only one place
• Prefer parent POM or platform BOM
• Never redefine versions already managed by a BOM
• Enforce dependency rules in CI using Maven Enforcer Plugin
• Treat build warnings as errors in enterprise pipelines
• Regularly review dependency trees

How to Detect Duplicating Managed Version Early

Use the following commands to detect hidden overrides and duplicates:

mvn help:effective-pom
mvn dependency:tree

Why This Matters in Production

Duplicating managed version issues can lead to different versions in different microservices, inconsistent QA and production behavior, increased regression risk, and security patch failures. For software engineers working in companies, clean dependency management is as important as clean code.

Conclusion

The Duplicating managed version problem is not just a Maven warning. It is a design smell that signals poor dependency governance. By understanding the root cause, reproducing the issue deliberately, and applying one of the proven solutions discussed in this post, you can eliminate this problem permanently from your enterprise builds.

Centralized management, correct BOM usage, and strict discipline are the keys. When dependency versions are managed cleanly, your builds become predictable, maintainable, and production-ready. This solution is ready to use in real company projects and aligns with enterprise software engineering best practices.