Maven
Eclipse
Dependency Management
Version Conflict
Software Development

Maven - Suppress Overriding managed version warning in Eclipse

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

The "Overriding managed version" warning in Eclipse usually means m2e has detected a dependency version in your dependencies section that conflicts with a version already managed by a parent POM or imported BOM. The best fix is usually not suppression at all, but cleaning up the POM so version management happens in one place.

Why Eclipse Shows the Warning

In Maven, a parent POM or a dependencyManagement section can define dependency versions centrally. Child modules can then reference those dependencies without repeating the version.

This parent configuration is common:

xml
1<dependencyManagement>
2  <dependencies>
3    <dependency>
4      <groupId>org.slf4j</groupId>
5      <artifactId>slf4j-api</artifactId>
6      <version>2.0.13</version>
7    </dependency>
8  </dependencies>
9</dependencyManagement>

If a child module then writes:

xml
1<dependencies>
2  <dependency>
3    <groupId>org.slf4j</groupId>
4    <artifactId>slf4j-api</artifactId>
5    <version>1.7.36</version>
6  </dependency>
7</dependencies>

Eclipse warns because you are overriding a centrally managed version. Sometimes that is intentional, but often it is just noise caused by duplicate configuration.

Preferred Fix: Remove the Redundant Version

If the parent or BOM already manages the version you want, remove the child version entirely.

xml
1<dependencies>
2  <dependency>
3    <groupId>org.slf4j</groupId>
4    <artifactId>slf4j-api</artifactId>
5  </dependency>
6</dependencies>

That keeps version control in one place and makes upgrades easier. It is the cleanest solution because it solves both the Eclipse warning and the underlying configuration duplication.

If You Intentionally Override, Do It Deliberately

Sometimes you do need a different version in one module. In that case, the warning is not necessarily wrong. It is telling you that the module is diverging from the managed dependency set.

If the override is truly required, first confirm that it is safe:

  • Check transitive compatibility.
  • Verify tests against the effective dependency tree.
  • Document why this module differs.

You can inspect the resolved result with Maven:

bash
mvn dependency:tree

That is more useful than merely hiding the IDE warning, because it tells you what will actually be used at build time.

How to Lower or Ignore the Warning in Eclipse

If your team has decided the override is intentional and frequent, m2e lets you change the warning severity in Eclipse preferences.

The usual path is:

  • 'Window'
  • 'Preferences'
  • 'Maven'
  • 'Errors/Warnings'
  • 'Overriding managed version'

You can change it from warning to ignore. That affects the IDE only; it does not change Maven behavior or the generated build.

This is why suppressing the warning in the IDE should be the last step, not the first. If the POM is wrong, hiding the warning only makes the configuration harder to notice later.

Common Pitfalls

The most common mistake is suppressing the warning without checking whether the child version is actually needed. Very often the extra version line is just leftover configuration that should be deleted.

Another issue is thinking the warning comes from Maven itself. The message usually comes from Eclipse m2e inspection, not from core Maven. The build may still succeed, but the warning is trying to tell you something useful about dependency management structure.

Teams also sometimes override versions in many child modules instead of updating the BOM or parent POM once. That creates a fragile dependency graph and makes upgrades painful.

Finally, do not rely only on what the POM looks like. Use mvn dependency:tree or similar tools to confirm the effective version Maven resolves after all management and transitive rules are applied.

Summary

  • The warning usually means a child module is overriding a version already managed centrally.
  • The best fix is often to remove the redundant child version entry.
  • If you intentionally override, confirm it with dependency analysis and tests.
  • Eclipse can downgrade or ignore the warning, but that only changes IDE behavior.
  • Prefer fixing dependency management structure before hiding the warning.

Course illustration
Course illustration

All Rights Reserved.