Dependency Management

Maven has six scopes: compile (default, everywhere), provided (compile/test only, supplied at runtime by the container), runtime (not for compiling, needed to run), test (only for tests), system (like provided but you give a local jar path), and import (only for BOMs in dependencyManagement).

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.

<dependencyManagement> declares versions (and other settings) centrally but does NOT add the dependency to the build. Child modules that list the same dependency without a version inherit the managed version. Plain <dependencies> actually pulls the jar onto the classpath.

provided is on the compile and test classpaths but NOT packaged or shipped, because something else (a container/JDK) supplies it at runtime. runtime is the opposite: NOT on the compile classpath but available (and packaged) for running and testing.

Add an <exclusions> block inside the direct dependency that drags it in, naming the unwanted groupId and artifactId. That prunes it (and its sub-tree) from the graph. Use it for clashing logging libs or vulnerable transitives.

Maven uses nearest-wins: the version closest to your project in the dependency tree (fewest hops) is chosen. If two are at the same depth, the one declared first in the POM wins.

A BOM (Bill of Materials) is a POM that only declares versions in its <dependencyManagement>. You import it by adding it inside your own <dependencyManagement> with <type>pom</type> and <scope>import</scope>. Then you use its libraries without specifying versions.

A -SNAPSHOT version (e.g. 1.2.0-SNAPSHOT) marks an in-development, mutable version. On a remote repo each deploy is stored with a unique timestamp, and Maven re-checks for newer SNAPSHOTs periodically (by default daily). Release versions are immutable.

A NoSuchMethodError usually means two versions of a library are in play. Run mvn dependency:tree -Dverbose -Dincludes=group:artifact to see which versions exist and who pulled them in, then fix it with an exclusion, a direct declaration, or dependencyManagement.

compile: all three (compile, test, runtime). provided: compile and test only. runtime: test and runtime only. test: test only. system: compile and test only (like provided). import: none of them (it only manages versions).

mvn dependency:analyze byte-code-scans your classes to compare what you actually use against what you declare. It flags 'used but undeclared' (relied on transitively — should declare directly) and 'declared but unused' (candidates to remove).

mvn dependency:go-offline pre-downloads every dependency and plugin your build needs into the local .m2 repository, so a later build can run with -o (offline) without hitting the network — ideal for Docker layer caching and air-gapped CI.

mvn dependency:purge-local-repository deletes this project's dependencies from the local .m2 cache and re-resolves them. You use it to recover from a corrupted/partial download or to force a stale SNAPSHOT to be re-fetched fresh.

import is not a classpath scope. Used only on a pom-typed dependency inside <dependencyManagement>, it merges another POM's <dependencyManagement> (a BOM) into yours, so you inherit managed versions without adding any jar to a classpath.

Maven narrows a transitive dependency's scope based on the scope of the direct dependency that pulled it in. A transitive provided (or system) dependency is dropped, so compile -> provided becomes none and you must redeclare it if you need it.

Run mvn dependency:tree (with -Dverbose) to find which versions of the artifact are in the graph and which one mediation chose. Then force the correct version via dependencyManagement or a direct declaration, and re-verify.

<optional>true</optional> marks a dependency you use internally but that should NOT propagate to projects that depend on you. It still applies to your own build; it just stops Maven passing it transitively to consumers.

A <properties> entry like <guava.version>33.2.1</guava.version> is just a reusable string you reference with ${guava.version}; you still write the version everywhere. <dependencyManagement> sets a managed default so child modules can omit the version entirely. Teams often combine both.

A version range like [1.0,2.0) lets Maven pick any matching version: square brackets are inclusive, parentheses exclusive. So that means >=1.0 and <2.0. Most teams instead pin an exact version (e.g. 1.4.2) for reproducible, predictable builds.

dependency:copy-dependencies copies your project's resolved dependency jars into a folder (default target/dependency). Unlike a fat/shaded jar, it leaves them as separate files — useful for a Class-Path/-cp layout or for Docker images that cache deps separately from app code.

system scope behaves like provided but Maven does not search any repository; you must give an absolute path to the jar via <systemPath>. It is discouraged because it ties the build to a local file, breaks portability and reproducibility, and the jar is never packaged.