skip to content

Lifecycles & Phases

The clean, default, and site lifecycles and the phase order validate→compile→test→package→verify→install→deploy, where naming one phase runs every phase before it. A rapid-fire favorite: what is the difference between install and deploy?

on this pageshow

questions

5

Walk through the key phases of the default lifecycle in order and explain what typically happens at each.

level: juniorimportance: must knowfreq 75%

answer

  1. validate→compile→test→package→verify→install→deploy
  2. test = Surefire unit
  3. verify = Failsafe IT
  4. install = local .m2
  5. deploy = remote repo

basics

~20 s

The main default phases run in order: validate, compile, test, package, verify, install, deploy. Validate checks the project, compile builds source, test runs unit tests, package makes the jar/war, verify runs checks, install copies to the local repo, deploy uploads to a remote repo.

solid answer

~40 s

The default lifecycle's headline phases are validate → compile → test → package → verify → install → deploy. validate checks the project is correct and all needed info is available. compile compiles main sources to target/classes. test runs unit tests with a suitable framework (Surefire), without packaging. package bundles compiled code into the distributable format defined by <packaging> (jar/war). verify runs checks on the package's results, classically integration tests via Failsafe and quality gates. install copies the artifact into the local repository (~/.m2/repository) so other local projects can use it. deploy pushes it to a remote repository for sharing. There are also finer phases between these (e.g. process-resources, prepare-package, integration-test) but these seven are what you name in interviews.

code

bash · 3 lines
bash
mvn package   # runs validate, compile, test, package
mvn install   # ... then install into ~/.m2
mvn deploy    # ... then upload to remote repository

go deeper

for a junior

Recite the seven phases in correct order with a one-line description.

for a middle

Explain Surefire vs Failsafe and the sub-phases like process-resources / test-compile.

for a senior

Reason about where to gate quality (verify) vs fail fast (test), and install vs deploy in CI pipelines.

for a principal

Set org-wide policy: when artifacts get deployed, snapshot vs release repos, reproducibility, and standard phase bindings.

## The default lifecycle, end to end The **default lifecycle** is the one that actually builds and distributes your project. It has many phases; the commonly cited milestones, in order, are: - **validate** — verify the project is correct and all necessary information is available (e.g. POM is well-formed, required properties set). - **compile** — compile the main source code into `target/classes` (via `maven-compiler-plugin:compile`). - **test** — run **unit tests** against the compiled code using a test framework, executed by `maven-surefire-plugin:test`. Tests run from compiled classes; the project is NOT yet packaged. - **package** — take the compiled code and bundle it into its distributable format — a `jar`, `war`, etc. — based on the `<packaging>` element. For a jar this is `maven-jar-plugin:jar`. - **verify** — run any checks to verify the package is valid and meets quality criteria. This is the conventional home of **integration tests** (`maven-failsafe-plugin`) and quality gates. - **install** — install the packaged artifact into the **local repository** (`~/.m2/repository`) so other projects on the same machine can depend on it. - **deploy** — copy the final artifact to a **remote repository** (e.g. Nexus/Artifactory) to share with other developers and CI. ## Finer-grained phases Between these milestones Maven defines sub-phases such as `initialize`, `generate-sources`, `process-sources`, `generate-resources`, `process-resources`, `process-classes`, `generate-test-sources`, `process-test-resources`, `test-compile`, `prepare-package`, `pre-integration-test`, `integration-test`, `post-integration-test`. You bind plugins to these for fine control. ## Unit vs integration tests A classic distinction: **Surefire** runs unit tests at `test`; **Failsafe** runs integration tests at `integration-test`/`verify`. Failsafe is designed so a failing IT still lets `post-integration-test` tear down resources before the build fails at `verify`. ```bash mvn package # validate, compile, test, then package mvn verify # also runs integration tests / checks after package mvn deploy # full chain up to remote upload ```

  • What is the difference between install and deploy?
    install copies the artifact into the local repository (~/.m2) on your machine; deploy uploads it to a remote/shared repository for other developers and CI.
  • At which phase do integration tests conventionally run?
    At integration-test/verify via the maven-failsafe-plugin, after package, so the artifact under test actually exists.

saying these in an interview costs you the question

  • Saying package runs before test
  • Claiming unit tests run at the package phase rather than test
  • Thinking deploy means deploying to a production server (it means publishing to an artifact repository)

context

open as a page

What are Maven's three built-in build lifecycles, and what is each one responsible for?

level: juniorimportance: must knowfreq 70%

basics

~10 s

Maven has three built-in lifecycles: clean (deletes previous build output), default (builds, tests, packages and deploys the project), and site (generates project documentation/reports).

open as a page

When you run 'mvn package', what exactly executes, and why? Explain the cumulative nature of phases.

level: middleimportance: must knowfreq 65%

basics

~10 s

Invoking a phase runs that phase AND every phase before it in the same lifecycle, in order. So 'mvn package' runs validate, compile, and test before package, executing all goals bound to each.

open as a page

Describe the clean and site lifecycles, including their phases, and explain why 'mvn clean package' is a common command.

level: middleimportance: should knowfreq 45%

basics

~20 s

The clean lifecycle (pre-clean, clean, post-clean) deletes the target directory. The site lifecycle (pre-site, site, post-site, site-deploy) builds project docs. 'mvn clean package' is common because it deletes old output first, then does a fresh build.

open as a page

How do plugin goals get associated with lifecycle phases, and how can you bind your own goal to a specific phase?

level: seniorimportance: should knowfreq 55%

basics

~10 s

Lifecycle phases run plugin goals bound to them. Some bindings are default (chosen by packaging type); you add your own by declaring a plugin <execution> with a <phase> and <goals> in the POM's <build><plugins>.

open as a page