Understanding Maven: From Pre‑Maven Days to Dependency Management and Configuration

Before Maven, developers had to manually download JAR files, place them in a lib directory, add that directory to CLASSPATH , and resolve transitive dependencies and version conflicts by hand, which was time‑consuming and error‑prone.

Maven introduced a centralized package management system for Java, similar to yum for Linux or webpack for front‑end, allowing automatic retrieval of artifacts from local, private, or central repositories (e.g., http://repo1.maven.org/maven2/ ).

The settings.xml file, located in ${maven.home}/conf or ~/.m2 , configures repository locations, mirrors, proxies, and other global settings; the default local repository path is ${user.home}/.m2/repository .

Maven projects follow a conventional directory layout: ${project.basedir}/src/main/java for source code, ${project.basedir}/src/main/test for tests, and ${project.basedir}/target for compiled output, embodying the "convention over configuration" principle.

The Maven installation includes several directories: bin (scripts that set up the classpath and launch Maven), boot (contains plexus‑classworlds class‑loader), conf (holds settings.xml ), and lib (runtime libraries and third‑party dependencies).

Common Maven commands are summarized in a table, e.g., mvn clean removes the target directory, mvn compile compiles source files, mvn package creates JAR/WAR artifacts, mvn install copies the artifact to the local repository, and mvn dependency:tree prints the full dependency graph.

The pom.xml file defines groupId , artifactId , version , and packaging . Dependency scope controls inclusion: compile (default, included), test (only for tests), provided (needed for compilation but not packaged), runtime (needed at runtime), and system (local JAR with explicit path, rarely used).

Examples of provided and runtime scopes are shown, such as spring-boot-starter-tomcat (provided) and mysql-connector-java (runtime). The article also demonstrates a Lombok dependency with provided scope, confirming that Lombok code is compiled away.

Transitive dependency handling is illustrated with a multi‑module project diagram, showing how scopes propagate and how Maven chooses the shortest path (the "nearest‑definition" rule) when multiple versions of the same artifact are present.

Dependency arbitration (conflict resolution) follows the shortest‑path principle and the declaration‑order principle: the version from the nearest dependency wins, but if distances are equal, the version declared first in pom.xml is selected.

To exclude unwanted transitive dependencies, the <exclusions> element can be used inside a <dependency> block, as demonstrated with the exclusion of spring-boot-starter-logging from the Spring Boot starter.

Overall, the article provides a thorough guide to Maven's purpose, repository types, configuration files, project layout, command usage, POM structure, dependency scopes, transitive dependencies, conflict resolution, and exclusion techniques.