Version conflicts in Maven occur when different dependencies (direct or transitive) request incompatible versions of the same artifact. The standard fix is to pin an explicit version in the Dependency Management section of pom.xml, which overrides Maven's default nearest-wins resolution.
Key Points: • <dependencyManagement> lets you declare a specific version for an artifact once, which all modules and transitive requests then honor without needing to redeclare the version. • This differs from a plain <dependency> declaration, which only affects the current module rather than the whole reactor. • Exclusions (<exclusions>) can remove a specific transitive dependency entirely when you want a different library to supply it instead. • dependency:tree is used first to confirm exactly which paths bring in each conflicting version before deciding how to resolve it. • In multi-module projects, defining dependencyManagement in the parent POM ensures all child modules use the same resolved version automatically.
Example: If module-a and module-b each transitively depend on different versions of Jackson, declaring the desired Jackson version once in the parent POM's dependencyManagement ensures both modules use that single consistent version instead of whatever their nearest-wins resolution would otherwise pick.
Code Example:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.15.2</version>
</dependency>
</dependencies>
</dependencyManagement>Interview Tip: A concise interview answer is:
"I use the Dependency Management section in pom.xml to pin an explicit version for the conflicting artifact, which overrides Maven's default nearest-wins resolution across the whole project. Before doing that I run dependency:tree to confirm which modules are actually pulling in each version, so I'm fixing the real conflict rather than guessing."