Apache Maven - Java Build Tool That Everyone Uses

Maven has been the default Java build tool since 2004. It downloads dependencies for you and makes every project look the same, which is boring but useful when you're switching between codebases. Every Java shop uses the same directory structure, so you always know where to find shit.

The pom.xml File (Your New Best Friend and Worst Enemy)

Everything in Maven revolves around the pom.xml file - an XML configuration that tells Maven what your project is and how to build it. This file contains:

• Project coordinates: GroupId, ArtifactId, and Version (the holy trinity of Maven)
• Dependencies: All the libraries you need (and their transitive dependencies you don't want)
• Build settings: Plugins that actually do the work
• Random metadata: That nobody reads but Maven requires anyway

The pom.xml approach means you describe what you want instead of writing build scripts. When it works, it's fine. When it breaks, you'll be staring at XML trying to figure out what went wrong. The POM reference docs help when things break, and Sonatype's guide covers publishing requirements.

Standard Project Layout (Finally, Some Sanity)

Maven enforces a standard directory layout that every Java project follows. No more guessing where the source code lives:

src/main/java/          # Your actual Java code lives here
src/main/resources/     # Config files, properties, anything non-Java
src/test/java/          # Unit tests (that you definitely write, right?)
src/test/resources/     # Test config files
target/                 # Maven dumps all generated stuff here

This structure is the same across every Maven project. Walk into any Java shop and you'll immediately know where everything is. It's boring but incredibly useful when you're not the one who wrote the project.

Build Phases (The Magic Incantations)

Maven has three build lifecycles, but you'll mainly care about one:

1. Default lifecycle: Compiles, tests, and packages your code
2. Clean lifecycle: Deletes the target directory when things get weird
3. Site lifecycle: Generates docs that nobody reads

The default lifecycle has phases like validate, compile, test, package, verify, install, and deploy. Run mvn package and Maven automatically runs compile and test first. It's actually pretty smart about dependencies between phases, though it will happily run tests that take 20 minutes every time you want to create a JAR.

Dependency Management (When It Works)

Maven's dependency management system handles the nightmare of JAR file management. Maven automatically:

• Resolves transitive dependencies: Downloads all required libraries, including their dependencies
• Manages version conflicts: Uses dependency mediation to resolve version conflicts
• Handles different scopes: Supports compile, test, runtime, and provided scopes
• Integrates with repositories: Connects to Maven Central and other repositories with basically everything you'll ever need

This works great until you hit dependency hell - when two libraries need different versions of the same thing and Maven picks the wrong one. You'll end up running mvn dependency:tree and staring at 47 different versions of slf4j wondering why your app won't start. Maven caches everything in ~/.m2/repository which grows to several GB and occasionally corrupts, forcing you to delete it and re-download everything.

Common dependency problems that will ruin your day:

• Jackson conflicts: Spring Boot 3.1.5 brings Jackson 2.15.2, your legacy library needs 2.12.1, runtime fails with NoSuchMethodError
• Logging nightmares: slf4j-api 1.7.36, logback-classic 1.4.14, log4j-core 2.19.0, and commons-logging 1.2 all fighting each other until nothing logs
• Version mismatches: Library A wants Guava 31.1-jre, library B wants Guava 28.2-android, Maven picks 30.1.1-jre and breaks both
• Transitive bloat: Add spring-boot-starter-web, suddenly you have 47 dependencies including 3 different JSON parsers and a YAML library you never asked for

When dependencies break, use `dependency:tree` to see what's happening, `dependency:analyze` to find unused libraries, and the versions plugin to update everything. Baeldung's dependency guide explains how to exclude transitive dependencies.

Why Everyone Still Uses Maven

Maven is everywhere in enterprise Java because it's been around since 2004 and changing build tools is career suicide. I've watched three separate teams burn 6 months trying to migrate to Gradle - first team gave up when their CI randomly started failing with "Gradle daemon disappeared" errors, second couldn't get the Spring Boot plugin working with their custom deployment scripts, third one reverted after the gradle daemon started eating 4GB of RAM during builds and Jenkins started killing processes.

Your IDE already knows Maven. Your deployment scripts know Maven. That contractor who left 2 years ago wrote everything assuming Maven. The inertia is real.

Enterprises love Maven because it's boring and predictable. Your project will build exactly the same way in 5 years, assuming Oracle doesn't change their licensing again and your company doesn't decide to "go cloud native" and rewrite everything in Go.

Maven 4 (Coming Any Decade Now)

The Maven team has been working on Maven 4.0 since Java 8 was considered "modern". It's been in RC phase longer than some developers have been alive. Promises include:

• Better performance: 20% faster builds (we'll see)
• Improved BOM support: Because managing 200 versions manually wasn't fun enough
• Java 17+ requirement: Finally dropping Java 8 support, only 5 years after everyone else
• Consumer POM: Cleaner dependency declarations that will break existing tooling

Maven 4 claims backward compatibility with Maven 3, but we all know how that goes. Half your plugins will break, the other half will just stop working for mysterious reasons.

Will it ship this year? Maybe. Will your company upgrade within 3 years of release? Probably not. Enterprise Java shops are still running Maven 3.6.3 from 2019 and complaining about "stability".

Installation

Installing Maven is easy on Mac and Linux. On Windows, you'll fight PATH variables for a while. Common Windows issues:

• PATH problems: Maven in PATH but mvn command not found
• Space-in-path issues: Installing to "Program Files" breaks scripts
• JAVA_HOME wrong: Maven finds Java but uses wrong version
• Permission errors: Antivirus software blocking Maven

Current Maven version is 3.9.x and needs Java 8+ to run. Install it with brew install maven or whatever package manager your OS uses.

Maven Wrapper (The Smart Choice)

The Maven Wrapper bundles Maven with your project so everyone uses the same version:

./mvnw clean compile    # Unix/macOS
mvnw.cmd clean compile  # Windows

This prevents "works on my machine" problems and means new team members don't need to install Maven. It's great until the wrapper can't download Maven due to corporate firewalls, then you'll be debugging proxy settings in ~/.m2/settings.xml.

Core Maven Commands

Maven provides a command-line interface that's predictable once you memorize the incantations:

mvn archetype:generate    # Create new project from template
mvn clean compile        # Clean and compile source code
mvn test                 # Run unit tests
mvn package             # Create JAR/WAR artifacts
mvn install             # Install to local repository
mvn deploy              # Deploy to remote repository

IDE Integration (Mostly Works)

IntelliJ IDEA

IDEA has decent Maven support when it's not having a stroke. Multi-module projects will drive you insane - you'll click "Reimport Maven projects" 47 times while IntelliJ shows that spinning wheel of death and consumes 8GB of RAM indexing the same files over and over, then crashes and corrupts its caches. Common issues that will waste your day:

• "Cannot resolve symbol" for classes that compile perfectly with mvn compile
• Import loops when IDEA gets confused about parent POMs and builds forever
• Test failures that pass in IDEA but fail in mvn test because of different classpaths
• Module dependencies disappearing after IDEA updates, because why would things just work?
• Random freezing during Maven import on projects with 20+ modules
• Wrong source roots after importing, so your src/main/java isn't actually recognized as source

Eclipse IDE

Eclipse's M2Eclipse plugin works fine until you try to do anything interesting. Multi-module projects require frequent workspace cleaning, Eclipse restarts, and sacrificial offerings to the plugin gods. Expect import errors that make no sense and can only be fixed by deleting .metadata and reimporting everything.

Visual Studio Code

VS Code's Java Extension Pack actually works pretty well for small projects. It's the scrappy underdog that sometimes outperforms the heavyweight IDEs. Debugging is hit-or-miss - sometimes it works perfectly, sometimes it can't find the main class that's literally right there.

Maven Central (The Great Library of Alexandria, But With More Broken Links)

Maven Central hosts 4.5 million artifacts because apparently everyone needs to publish their "hello world" library. Browse at mvnrepository.com for a less shitty interface. Contains:

• Everything you need: Spring Boot, JUnit 5, Jackson 2.15.x, Apache Commons that hasn't been updated since 2018
• Automatic downloads: Add to pom.xml, Maven downloads them, your security team blocks them, you spend 2 hours configuring proxy settings
• Version hell: 47 versions of every library, Maven picks the broken one from 3 years ago
• Global CDN: Blazing fast unless you're on conference WiFi or your ISP hates Java developers

Maven Central has every Java library except the one you actually need, which exists only in some dead company's private Nexus that went offline in 2019. Also, that critical AWS SDK version you depend on? They yanked it last week for "security reasons" and your build is now fucked.

CI/CD (Works Until It Doesn't)

Maven plays nice with GitHub Actions, Jenkins, and whatever cursed CI system your company bought from the lowest bidder in 2019. The basic setup is straightforward:

- run: mvn clean package

But prepare for these greatest hits:

• Tests that pass locally but fail in CI because of timezone differences - usually date parsing tests that work fine in PST but explode in UTC
• Out of memory errors during mvn package on the 1GB RAM CI runner your company cheaped out on
• Random network timeouts downloading dependencies because the CI server is in Ohio and Maven Central is having a bad day
• Flaky integration tests that fail 30% of the time, but management says "just retry the build" instead of fixing the actual problem
• Build cache corruption that requires nuking the entire CI pipeline storage and starting over, losing 6 months of cached artifacts

Pro tip: Always run mvn clean package -DskipTests first to see if your code even compiles, because you'll save 15 minutes of waiting before discovering you forgot to import a class.

Multi-Module Projects (Abandon All Hope)

Large projects split into multiple modules because someone read a microservices blog post. In theory, you build just the piece you're working on. In practice, you'll spend 3 hours figuring out why user-service can't find classes from common-utils, even though IntelliJ shows everything is fine and displays a nice green checkmark.

Multi-module builds fail in ways that defy physics:

• Circular dependencies: Module A needs B, B needs C, C needs A. Maven just throws up its hands
• Version mismatches: Parent POM declares 1.0-SNAPSHOT, child modules use 1.1-SNAPSHOT, builds succeed locally but fail in CI
• IDE lies: IntelliJ imports perfectly, shows no errors, but mvn clean install fails with "package does not exist"
• Build order chaos: Maven builds modules alphabetically unless you specify <dependencies> correctly, which you won't

The Maven Release Plugin handles version bumping across 47 modules, but it's more finicky than a cat. It will fail if you have:

• Uncommitted changes (obviously)
• Untracked files (seriously?)
• Wrong git branch (fuck you, develop branch)
• Corporate firewall blocking SCM access (classic)

Expect to spend a full sprint making the release plugin work with your specific combination of Git hosting, Jenkins setup, and corporate security policies. Check Baeldung's multi-module guide for patterns that might work, but your project is special and definitely won't fit any of them.