All 15 Build Tools: Maven & Gradle questions
More in Build Tools: Maven & Gradle
What problem do build tools like Maven and Gradle solve for a Java project? What is the standard Maven directory layout, and why does following this convention matter? How does Gradle's build script (build.gradle / build.gradle.kts) differ structurally from Maven's declarative XML pom.xml? What is the difference between Maven's <dependencies> scope values (compile, provided, runtime, test) and how do they affect what's included in the final packaged artifact? How do you resolve a dependency version conflict manually in Maven using exclusions, and when would this be necessary despite the automatic nearest-wins resolution? What is a Maven BOM (Bill of Materials), and how does it help manage consistent dependency versions across a multi-module project or organization? How do you manage different configurations for different environments (development, staging, production) using Maven profiles or Gradle's equivalent mechanisms? How do you configure the Maven Compiler Plugin to target a specific Java language version, and what's the difference between source, target, and release configuration? How does Maven's dependency resolution algorithm handle transitive dependency version conflicts, and what is the "nearest definition wins" rule? How does Gradle's incremental build and build cache mechanism achieve significantly faster rebuild times compared to Maven's default behavior?
Advertisement
Back to results for “UI Testing”
Java › Build Tools: Maven & Gradle

What is the Maven build lifecycle, and what do the common phases (validate, compile, test, package, install, deploy) each do?

Intermediate

Answer

Maven's default lifecycle is a fixed, ordered sequence of phases, where running any given phase automatically executes all preceding phases in order: validate (checks project structure is correct), compile (compiles source code), test (runs unit tests via a test framework plugin like Surefire), package (bundles compiled code into a JAR/WAR), install (copies the package into the local ~/.m2 repository for use by other local projects), and deploy (publishes the package to a remote repository for sharing with other developers/environments) -- each phase is itself bound to specific plugin goals that do the actual work.
# Running 'mvn package' automatically runs validate, compile, and test first
mvn package

# Running 'mvn install' runs everything through package first, then installs to ~/.m2
mvn install

# Skip tests during a phase (use sparingly)
mvn package -DskipTests
Real-world example A CI pipeline runs `mvn clean install` on every pull request, which automatically compiles, tests, and packages the code in one command, failing the build immediately if any earlier phase (like a failing unit test) doesn't succeed, preventing broken code from progressing further in the pipeline.

Common follow-ups: What's the difference between skipping tests with -DskipTests versus -Dmaven.test.skip=true?;How would you bind a custom plugin goal to run during a specific lifecycle phase?

Testing Strategy;Deploy Checklist
All 15 Build Tools: Maven & Gradle questions