Master Maven: Resolve Dependency Conflicts and Master the Build Lifecycle

In modern Java web development Maven is ubiquitous; its repository management, dependency handling, inheritance, and aggregation provide a complete build solution, and misunderstanding it can cause painful multi‑module headaches.

Thinking in Maven

When you join a new company you typically install JDK, set up MAVEN_HOME and PATH, and often edit settings.xml to point to a local repository or a private mirror. After configuring the IDE (IDEA or Eclipse) you start adding <dependency> tags in pom.xml, write code under Maven's standard directory layout, and use plugins to test, package (jar/war), deploy and run.

Q1: What are Maven repositories and how do they relate?

The local repository acts as a cache for JARs; if a JAR isn’t found locally Maven checks the private repository, then the central repository (http://repo1.maven.org/maven2/). Private repositories are internal servers that store company‑specific artifacts and often mirror the central repository.

Q2: How to use the <dependency> tag

The tag defines the coordinates groupId, artifactId, and version. You can search for coordinates on private servers, search.maven.org or mvnrepository.com . Versions are either Snapshot (development) or Release (stable). Snapshots allow a dependent project to always pick the latest timestamped build, avoiding manual version bumps during active development.

Q3: Why do dependency conflicts still happen and how to solve them?

Maven can only use one version for a given groupId / artifactId. If two direct dependencies pull different versions of the same transitive dependency, the version that is nearest to the root in the dependency tree wins (Maven’s “nearest‑first” strategy). This can cause ClassNotFoundException or NoSuchMethodError at runtime.

Resolution methods:

Use <dependencyManagement> to enforce a single version across modules.

Apply <exclusions> to remove unwanted transitive dependencies.

Declare the desired version explicitly in your own <dependency> entry.

Q4: Best practice – detect problems early

Before adding a new dependency, run mvn dependency:tree to view the full tree, check for transitive dependencies and version clashes, and resolve them using the techniques above.

Q5: Maven’s standardized directory structure

Key points: src/main is packaged into the final JAR/WAR. src/test contains test code and is not packaged.

Resources under src/main/resources are copied to the output directory (e.g., Hibernate or MyBatis XML files must reside here).

Q6: Maven lifecycle

Important phases you’ll use most often:

clean : removes previous build output.

package : creates a JAR or WAR (implicitly runs clean and compile).

install : copies the artifact to the local repository.

deploy : uploads the artifact to a remote repository.

Q7: Dependency scopes

Different scopes control when a dependency is available:

compile (default): needed at compile time and packaged.

provided : needed at compile time but supplied by the runtime container (e.g., servlet-api).

runtime : not needed for compilation but required at execution.

test : only for test code, not packaged.

system : external JARs outside the repository (rarely used).

Understanding these scopes helps keep the final artifact lean and avoids unnecessary conflicts.