Maven Dependency Scopes: compile, test, provided, runtime

Maven's five dependency scopes control which classpaths a dependency appears on and whether it ships in the packaged artifact. Getting scopes wrong is a common source of both bloated artifacts and production ClassNotFoundException errors.

Compile and test — the most common scopes

• compile (the default) goes on every classpath: compile, test, and runtime; it ships in the final JAR — use it for core libraries your code directly imports and consumers of your library also need
• test restricts the dependency to test compilation and execution only — JUnit, Mockito, AssertJ belong here; they never appear in the final package and never reach production; forgetting test scope on Mockito ships it to production unnecessarily
• runtime is not needed to compile but must be on the runtime classpath — JDBC drivers fit perfectly because you code against java.sql interfaces, not the driver classes; compile scope on a driver adds unnecessary compile-time coupling

Provided — the shared-runtime trap

• provided means the container or runtime environment supplies the dependency — the Servlet API on Tomcat, Lombok during annotation processing; the dependency is on the compile classpath but excluded from the final package
• Packaging a Spring Boot fat JAR with Tomcat as compile scope includes an embedded container; packaging it as provided correctly excludes it when deploying to an external Tomcat
• Lombok must be provided (or optional) — including it as compile ships it to consumers of your library who may be using a different version

Scope verification before deployment

• mvn dependency:tree -Dscope=runtime shows exactly what ships in the final artifact — run this before every release to catch accidentally included test or compile-only dependencies
• The most painful scope bugs surface as ClassNotFoundException in production: a library was provided in a context where no container supplied it, or test scoped in a module that shipped it to a WAR