Transitive Dependencies in Maven
Fast recall
Quick revision
Core answer
Understanding of Maven's dependency resolution mechanism and awareness that your project's classpath is larger than your pom.xml suggests
Thinking you only have the dependencies you explicitly declared, not realizing transitive deps can introduce hundreds of JARs
Explain Maven's nearest-wins strategy and mention using dependency:tree to diagnose conflicts, or exclusions to resolve them
Interview-ready guide
Interview answer
Transitive dependencies are dependencies of your dependencies.
xml, Maven doesn't just download that one JAR—it also downloads everything that library needs, and everything those need, creating a whole tree of dependencies. This is usually helpful because you don't have to manually track every single library.
For example, if you add Spring Boot Starter Web, it transitively pulls in Jackson for JSON, Tomcat for the embedded server, and dozens of other libraries. You only declare one dependency but get everything you need. The problem is that this automation can create conflicts.
Let's say you add Library A which depends on Apache Commons Lang version two point six, and Library B which depends on Commons Lang version three point twelve. Maven has to pick one version—it can't have both on the classpath. It uses a nearest-wins strategy, meaning if one version is closer to your pom in the dependency tree, that's the one Maven chooses.
If they're at the same depth, Maven picks whichever you declared first. This means one of your libraries might end up with the wrong version and crash at runtime with NoSuchMethodError.
A common mistake freshers make is looking at their pom with maybe ten dependencies and thinking that's all they have. But a typical Spring Boot project actually has a hundred to two hundred JARs on the classpath because of transitive dependencies. When something breaks in production, it's often a transitive dep you didn't even know you had.
You can diagnose these issues by running mvn dependency:tree, which shows the full tree of what Maven resolved. If you find a conflict, you can use exclusions to block the problematic transitive dependency and add the correct version directly in your pom.
Transitive Dependencies in Maven
Direct Answer
Transitive dependencies are dependencies of your dependencies—Maven automatically downloads them. They cause problems when two libraries depend on different versions of the same artifact, leading to version conflicts, ClassNotFoundException, or unexpected behavior at runtime.
Code Example
<!-- Your pom.xml: only 2 explicit dependencies -->
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<version>3.2.0</version>
<!-- Transitively pulls in: -->
<!-- spring-web, spring-webmvc, jackson-databind -->
<!-- jackson-core, jackson-annotations, tomcat-embed-core -->
<!-- slf4j-api, logback-classic, and 30+ more -->
</dependency>
<dependency>
<groupId>org.apache.commons</groupId>
<artifactId>commons-csv</artifactId>
<version>1.10.0</version>
<!-- Transitively pulls in commons-io 2.11.0 -->
</dependency>
</dependencies>
// Runtime surprise: commons-io is on your classpath
import org.apache.commons.io.FileUtils; // compiles even though you never added commons-io
public class ReportService {
public void cleanupOldReports() {
var directory = new File("/tmp/reports");
FileUtils.deleteDirectory(directory); // works because commons-csv brought commons-io
}
}
Common Mistakes & Pitfalls
- Assuming your classpath is just your pom dependencies: Freshers look at their pom.xml with 10 dependencies and think that's their entire classpath. Then they run dependency:tree and see 150 JARs, wondering where they came from. Every dependency can pull in dozens more, and you're responsible for all of them—including security patches.
- Ignoring Maven's version resolution: Maven picks one version when conflicts occur, but freshers don't realize which version won. They assume "newest wins" but Maven actually uses nearest-wins. If a critical library gets downgraded by a transitive dep closer to your pom, you might have bugs or security holes. Use dependency:tree to verify the actual resolved version.
- Not excluding unwanted transitive deps: When you add a library that brings in logging frameworks you don't use (like commons-logging when you're using SLF4J), freshers let both coexist. This causes two logging systems to fight for control, producing confusing log output or silent failures. You should exclude the unwanted logger to prevent conflicts.
Check your understanding
Answer these without looking back at the article.
- How do you exclude a specific transitive dependency?
- What is 'mvn dependency:tree'?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.