skip to content

What are transitive dependencies in Maven, and where do they come from?

level: juniorimportance: must knowfreq 75%

answer

  1. dependency of a dependency
  2. transitive closure / graph
  3. each artifact ships its own POM
  4. mvn dependency:tree
  5. convenience vs hidden conflicts

basics

~10 s

Transitive dependencies are the dependencies of your dependencies. If you declare library A and A needs B, Maven automatically downloads B too, so you don't have to list it yourself.

solid answer

~40 s

Maven builds a full dependency graph: you declare direct dependencies in your pom.xml, and each of those declares its own dependencies in its published POM, recursively. Maven pulls in that whole transitive closure automatically so you only list what you directly use. Each artifact publishes a POM to the repository describing its dependencies, which is how Maven knows the graph. Transitivity is filtered by scope (e.g. test and provided don't propagate the same way) and can be controlled with <exclusions> to prune unwanted branches and <optional>true</optional> to stop propagation. You can inspect the resolved graph with `mvn dependency:tree`. The benefit is convenience; the risk is pulling in unexpected or conflicting versions, which is why mediation and exclusions exist.

code

bash · 5 lines
bash
mvn dependency:tree
# [INFO] com.example:app:jar:1.0
# [INFO] +- org.springframework:spring-web:jar:6.1.0:compile
# [INFO] |  +- org.springframework:spring-core:jar:6.1.0:compile   (transitive)
# [INFO] |  \- org.springframework:spring-beans:jar:6.1.0:compile  (transitive)

go deeper

for a junior

Know that a dependency's dependencies come in automatically and that mvn dependency:tree shows them.

for a middle

Understand the transitive closure is read from each artifact's POM and filtered by scope.

for a senior

Reason about the trade-off: convenience vs uncontrolled graph growth and conflict risk; use dependency:tree routinely.

for a principal

Set org-wide policy: lock the graph via dependencyManagement/BOMs, enforce with enforcer rules, audit transitive bloat and CVEs.

## What "transitive" means A **direct dependency** is one you write yourself in your project's `pom.xml` (the Project Object Model — Maven's build configuration file). A **transitive dependency** is a dependency of a dependency: something you never named, but that gets pulled in because something you DID name needs it. Example: you depend on `spring-web`. `spring-web` itself depends on `spring-core` and `spring-beans`. You never wrote those, but Maven adds them to your classpath automatically. The complete recursively-collected set is called the **transitive closure** or **dependency graph**. ## How Maven knows the graph Every artifact published to a Maven repository ships with its own POM file alongside the JAR. That POM lists the artifact's own `<dependencies>`. Maven reads it, then reads the POMs of THOSE dependencies, and so on, walking the tree until it has the full closure. ## Why it exists - You only declare what you actually use; the build figures out the rest. - Upgrading one library can automatically bring compatible versions of its requirements. ## The cost - You may get JARs you never asked for. - Two different paths may demand different versions of the same artifact (a **version conflict**), which Maven resolves via **mediation** (nearest-wins). - Unwanted branches must be cut with `<exclusions>`. ## Inspecting it ```bash mvn dependency:tree ``` This prints the whole tree, marking direct vs transitive and showing where versions were omitted for conflict. Concepts to know: scope (controls propagation), `<exclusions>` (prune a branch), `<optional>true</optional>` (don't propagate to consumers).

  • How does Maven physically know what a third-party library depends on?
    Each published artifact has a companion POM file in the repository listing its own dependencies; Maven downloads and reads it to recurse the graph.
  • Does every scope propagate transitively the same way?
    No. compile and runtime propagate; test and provided do not propagate to downstream consumers, so a library's test dependencies never land on your classpath.

Like inviting one friend to dinner who brings their roommates: you only invited one person, but a whole chain shows up because each guest brings their own required companions.

saying these in an interview costs you the question

  • Saying you must manually declare every JAR you need — defeats the purpose of transitivity.
  • Claiming Maven scans the JAR bytecode to discover dependencies (it reads the published POM, not the bytecode).

context

resolving links…