What are Maven's three built-in build lifecycles, and what is each one responsible for?
answer
- clean / default / site
- default = build+test+deploy
- clean = delete target
- site = docs/reports
- lifecycles independent
basics
~10 sMaven has three built-in lifecycles: clean (deletes previous build output), default (builds, tests, packages and deploys the project), and site (generates project documentation/reports).
solid answer
~40 sMaven ships with three built-in lifecycles. The default lifecycle handles the actual build: validating, compiling, testing, packaging, verifying, installing and deploying the artifact. The clean lifecycle removes outputs from prior builds (it deletes the target directory via the maven-clean-plugin). The site lifecycle generates the project's documentation site and reports. Each lifecycle is an ordered list of phases; the three are independent, so running 'mvn clean' does not trigger default phases and vice versa. In practice you often chain them, e.g. 'mvn clean install', which runs the clean lifecycle through its clean phase and then the default lifecycle up to install. Plugin goals are bound to phases to do the real work; the lifecycle itself just defines the ordered sequence.
code
bash · 2 linesmvn clean install # clean lifecycle then default lifecycle
mvn site # site lifecycle onlygo deeper
Name the three lifecycles and one sentence on each.
Explain they are independent and that goals are bound to phases within them.
Discuss when to bind custom executions to clean vs default vs site and packaging-driven defaults.
Govern conventions across many modules: standardize when teams hook reporting into site vs verify, avoid abusing clean for non-cleanup work.
## What a lifecycle is Maven does not hardcode build steps; instead it defines **lifecycles**. A *lifecycle* is a named, ordered list of **phases**. A *phase* is a stage in the build (like 'compile' or 'test'). The real work is done by **plugin goals** that are *bound* to phases. So a lifecycle is essentially a schedule that says "at this phase, run whatever goals are bound here." ## The three built-in lifecycles - **clean** — removes the artifacts of previous builds. Its main phase, `clean`, is bound to the `clean` goal of the `maven-clean-plugin`, which deletes the `target/` directory. Phases: `pre-clean`, `clean`, `post-clean`. - **default** — the core lifecycle that produces and distributes your artifact. It contains the long sequence `validate → … → compile → … → test → … → package → … → verify → install → deploy`. What goals run depends on the project **packaging** (jar, war, pom…), which selects a default set of plugin bindings. - **site** — generates a documentation/report website for the project using the `maven-site-plugin`. Phases: `pre-site`, `site`, `post-site`, `site-deploy`. ## They are independent The three lifecycles do not invoke each other. `mvn clean` runs ONLY the clean lifecycle; it will not compile or test. To both clean and build you list phases from different lifecycles on one command line. ```bash # Run clean lifecycle (through 'clean') then default lifecycle (through 'install') mvn clean install # Generate the documentation site mvn site ``` ## Why this matters Knowing there are three separate lifecycles explains why `mvn clean` alone never builds anything, and why you must say `clean install` to get a fresh build. It also explains where to bind your own plugin executions: pick the right lifecycle and phase.
- Does running 'mvn clean' also compile the project?No. clean and default are separate lifecycles; 'mvn clean' only runs the clean lifecycle's phases and deletes target. You need e.g. 'mvn clean compile'.
- Which plugin actually deletes target during the clean phase?The maven-clean-plugin's clean goal, bound by default to the clean phase.
Think of three separate to-do checklists: one to tidy the kitchen (clean), one to cook the meal (default), one to write up the recipe (site). Finishing one doesn't start another.
saying these in an interview costs you the question
- Saying clean automatically builds the project
- Claiming there is one giant lifecycle covering everything
- Confusing 'site' with deploying the artifact (site deploys docs, not the jar)