The build lifecycle

Written Explanation

Phases in order

The default lifecycle is a fixed sequence of phases. These are the main ones (Maven's reference page lists a few more small ones between them):

The rule that explains everything: running a phase runs every phase before it. mvn package is not "just package": it first validates, compiles, and tests.

Phases and plugin goals

A phase is only a name for a position in the sequence. The work is done by plugin goals attached to phases (lesson 2). For a JAR project the standard attachments are:

You can watch it happen. This is the real output of mvn compile and mvn package on the example project, reduced to the goal lines:

$ mvn compile
[INFO] --- resources:3.3.1:resources (default-resources) @ hello ---
[INFO] --- compiler:3.13.0:compile (default-compile) @ hello ---

$ mvn package
[INFO] --- resources:3.3.1:resources (default-resources) @ hello ---
[INFO] --- compiler:3.13.0:compile (default-compile) @ hello ---
[INFO] --- resources:3.3.1:testResources (default-testResources) @ hello ---
[INFO] --- compiler:3.13.0:testCompile (default-testCompile) @ hello ---
[INFO] --- surefire:3.2.5:test (default-test) @ hello ---
[INFO] --- jar:3.4.1:jar (default-jar) @ hello ---

The package run is the compile run plus the test steps plus the jar step. That is the answer to "why does package run the tests": test is earlier in the list than package. (The finer steps process-resources and test-compile sit between the main phases; in the output they appear as goals.)

What each command produces

For our small project mvn verify ran exactly the same goals as mvn package, because nothing is attached to verify yet.

mvn clean: a separate lifecycle

clean does not belong to the default list. It is a tiny lifecycle of its own whose job is to remove what the previous build generated: the target/ folder. Real output:

$ mvn clean
[INFO] --- clean:3.2.0:clean (default-clean) @ hello ---
[INFO] Deleting C:\...\hello\target

Afterwards the target folder no longer exists. Because it is separate, you combine it with other phases on one line:

mvn clean package

This deletes the old output and then builds everything from scratch, which is the most trustworthy build there is. Use it when something looks odd, for example a class you deleted still appears to exist.

Which command when

A short guide for daily work:

Each of these is one line you can type in the project folder, and each does the same thing on a teammate's computer. Running mvn test very often is normal: it runs your safety net quickly, so most developers run it after every small change. A full mvn clean package is for when you want a trustworthy result, for example before sharing your work. Notice that mvn compile and mvn test do not create the JAR, so anything that depends on the JAR (like running java -jar) needs package.

Phases versus goals

You can also run a single plugin goal directly, as mvn dependency:tree in lesson 3. That is the form plugin:goal. A phase (like package) runs a chain; a goal runs one task. The commands for this module use phases, with dependency:tree as the one useful extra.

Skipping tests

Maven can skip tests with a flag: mvn -DskipTests package. Real output:

[INFO] --- surefire:3.2.5:test (default-test) @ hello ---
[INFO] Tests are skipped.
[INFO] --- jar:3.4.1:jar (default-jar) @ hello ---

The test phase still ran, but did nothing. It is legitimate in rare cases, such as when a teammate asks for the JAR quickly, but building without tests removes the safety net: you could publish a broken program. Treat it as an exception, never a habit.

Where the analogy stops

A recipe's steps can be done in any order you like. Maven's order is fixed: you cannot ask for package and say "except compile". And a recipe has no "clean the kitchen" in its numbered list; in Maven it is a separate lifecycle you add yourself.