Handling an incompatible dependency version in Maven means overriding the version Maven would otherwise resolve, either by pinning it directly or by excluding the conflicting transitive dependency so a compatible one is used instead. This keeps the classpath consistent and avoids runtime errors.
Key Points: • Declare the desired version explicitly in <dependencyManagement> so it takes precedence over whatever transitive dependencies request. • Use <exclusions> inside a <dependency> block to remove a specific transitive dependency pulled in by another library. • Check compatibility carefully — overriding a version can introduce its own breaking changes, so test after pinning. • mvn dependency:tree helps confirm which dependency is bringing in the incompatible version before you override it. • As a last resort, shading (via maven-shade-plugin) can relocate conflicting classes so two versions coexist without colliding on the classpath.
Example: If library A requires Guava 31 but library B transitively pulls in the incompatible Guava 20, adding an exclusion on library B's Guava dependency and declaring Guava 31 explicitly in your own POM ensures only the compatible version ends up on the classpath.
Code Example:
<dependency>
<groupId>com.example</groupId>
<artifactId>library-b</artifactId>
<version>2.0</version>
<exclusions>
<exclusion>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>31.1-jre</version>
</dependency>Interview Tip: A concise interview answer is:
"I'd first use dependency:tree to confirm exactly which transitive dependency is bringing in the incompatible version, then either exclude it from the offending dependency or pin the correct version explicitly in dependencyManagement. After that I'd run the full test suite, since overriding a version can introduce its own compatibility issues."