Maven 目标和阶段是什么，它们有什么区别？

Question

What is the difference/relation between Maven goals and phases? How they are related to each other?

Answer 1

Goals are executed in phases which help determine the order goals get executed in. The best understanding of this is to look at the default Maven lifecycle bindings which shows which goals get run in which phases by default. The compile phase goals will always be executed before the test phase goals, which will always be executed before the package phase goals and so on.

Part of the confusion is exacerbated by the fact that when you execute Maven you can specify a goal or a phase. If you specify a phase then Maven will run all phases up to the phase you specified in order (eg if you specify package it will first run through the compile phase and then the test phase and finally the package phase) and for each phase it will run all goals attached to that phase.

When you create a plugin execution in your Maven build file and you only specify the goal then it will bind that goal to a given default phase. For example, the jaxb:xjc goal binds by default to the generate-resources phase. However, when you specify the execution you can also explicitly specify the phase for that goal as well.

If you specify a goal when you execute Maven then it will run that goal and only that goal. In other words, if you specify the jar:jar goal it will only run the jar:jar goal to package your code into a jar. If you have not previously run the compile goal or prepared your compiled code in some other way this may very likely fail.

Answer 2

Life cycle is a sequence of named phases .
Phases executes sequentially. Executing a phase means executes all previous phases.

Plugin is a collection of goals also called MOJO ( M aven O ld J ava O bject).
Analogy : Plugin is a class and goals are methods within the class.

Maven is based around the central concept of a Build Life Cycles . Inside each Build Life Cycles there are Build Phases , and inside each Build Phases there are Build Goals .

We can execute either a build phase or build goal. When executing a build phase we execute all build goals within that build phase. Build goals are assigned to one or more build phases. We can also execute a build goal directly.

There are three major built-in Build Life Cycles :

1. default
2. clean
3. site

Each Build Lifecycle is Made Up of Phases

For example the default lifecycle comprises of the following Build Phases :

◾validate - validate the project is correct and all necessary information is available
◾compile - compile the source code of the project
◾test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
◾package - take the compiled code and package it in its distributable format, such as a JAR.
◾integration-test - process and deploy the package if necessary into an environment where integration tests can be run
◾verify - run any checks to verify the package is valid and meets quality criteria
◾install - install the package into the local repository, for use as a dependency in other projects locally
◾deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

So to go through the above phases, we just have to call one command:

mvn <phase> { Ex: mvn install }

For the above command, starting from the first phase, all the phases are executed sequentially till the 'install' phase. mvn can either execute a goal or a phase (or even multiple goals or multiple phases) as follows:

mvn clean install plugin:goal  

However, if you want to customize the prefix used to reference your plugin, you can specify the prefix directly through a configuration parameter on the maven-plugin-plugin in your plugin's POM.

A Build Phase is Made Up of Plugin Goals

Most of Maven's functionality is in plugins. A plugin provides a set of goals that can be executed using the following syntax:

 mvn [plugin-name]:[goal-name]

For example, a Java project can be compiled with the compiler-plugin's compile-goal by running mvn compiler:compile .

Build lifecycle is a list of named phases that can be used to give order to goal execution.

Goals provided by plugins can be associated with different phases of the lifecycle. For example, by default, the goal compiler:compile is associated with the compile phase , while the goal surefire:test is associated with the test phase . Consider the following command:

mvn test

When the preceding command is executed, Maven runs all goals associated with each of the phases up to and including the test phase. In such a case, Maven runs the resources:resources goal associated with the process-resources phase, then compiler:compile , and so on until it finally runs the surefire:test goal.

However, even though a build phase is responsible for a specific step in the build lifecycle, the manner in which it carries out those responsibilities may vary. And this is done by declaring the plugin goals bound to those build phases.

A plugin goal represents a specific task (finer than a build phase) which contributes to the building and managing of a project. It may be bound to zero or more build phases. A goal not bound to any build phase could be executed outside of the build lifecycle by direct invocation. The order of execution depends on the order in which the goal(s) and the build phase(s) are invoked. For example, consider the command below. The clean and package arguments are build phases, while the dependency:copy-dependencies is a goal (of a plugin).

mvn clean dependency:copy-dependencies package

If this were to be executed, the clean phase will be executed first (meaning it will run all preceding phases of the clean lifecycle, plus the clean phase itself), and then the dependency:copy-dependencies goal, before finally executing the package phase (and all its preceding build phases of the default lifecycle).

Moreover, if a goal is bound to one or more build phases, that goal will be called in all those phases.

Furthermore, a build phase can also have zero or more goals bound to it. If a build phase has no goals bound to it, that build phase will not execute. But if it has one or more goals bound to it, it will execute all those goals.

Built-in Lifecycle Bindings
Some phases have goals bound to them by default. And for the default lifecycle, these bindings depend on the packaging value.

Maven Architecture:

Reference 1
Reference 2

Eclipse sample for Maven Lifecycle Mapping

Answer 3

The chosen answer is great, but still I would like to add something small to the topic. An illustration.

It clearly demonstrates how the different phases binded to different plugins and the goals that those plugins expose.

So, let's examine a case of running something like mvn compile :

• It's a phase which execute the compiler plugin with compile goal
• Compiler plugin got different goals. For mvn compile it's mapped to a specific goal, the compile goal.
• It's the same as running mvn compiler:compile

Therefore, phase is made up of plugin goals .

Link to the reference

Answer 4

The definitions are detailed at the Maven site's page Introduction to the Build Lifecycle , but I have tried to summarize :

Maven defines 4 items of a build process:

1. Lifecycle

   Three built-in lifecycles (aka build lifecycles ): default , clean , site . ( Lifecycle Reference )

2. Phase

   Each lifecycle is made up of phases , eg for the default lifecycle: compile , test , package , install , etc.

3. Plugin

   An artifact that provides one or more goals.

   Based on packaging type ( jar , war , etc.) plugins' goals are bound to phases by default. ( Built-in Lifecycle Bindings )

4. Goal

   The task (action) that is executed. A plugin can have one or more goals.

   One or more goals need to be specified when configuring a plugin in a POM . Additionally, in case a plugin does not have a default phase defined, the specified goal(s) can be bound to a phase.

Maven can be invoked with:

1. a phase (eg clean , package )
2. <plugin-prefix>:<goal> (eg dependency:copy-dependencies )
3. <plugin-group-id>:<plugin-artifact-id>[:<plugin-version>]:<goal> (eg org.apache.maven.plugins:maven-compiler-plugin:3.7.0:compile )

with one or more combinations of any or all, eg:

mvn clean dependency:copy-dependencies package

Answer 5

I believe a good answer is already provided, but I would like to add an easy-to-follow diagram of the different 3 life-cycles ( build , clean , and site ) and the phases in each.

The phases in bold - are the main phases commonly used.

Answer 6

Credit to Sandeep Jindal and Premraj. Their explanation help me to understand after confused about this for a while.

I created some full code examples & some simple explanations here https://www.surasint.com/maven-life-cycle-phase-and-goal-easy-explained/ . I think it may help others to understand.

In short from the link, You should not try to understand all three at once, first you should understand the relationship in these groups:

• Life Cycle vs Phase
• Plugin vs Goal

1. Life Cycle vs Phase

Life Cycle is a collection of phase in sequence see here Life Cycle References . When you call a phase , it will also call all phase before it.

For example, the clean life cycle has 3 phases ( pre-clean, clean, post-clean ).

mvn clean

It will call pre-clean and clean .

2. Plugin vs Goal

Goal is like an action in Plugin . So if plugin is a class, goal is a method.

you can call a goal like this:

mvn clean:clean

This means "call the clean goal, in the clean plugin" (Nothing relates to the clean phase here. Don't let the word"clean" confusing you, they are not the same!)

3. Now the relation between Phase & Goal:

Phase can (pre)links to Goal (s).For example, normally, the clean phase links to the clean goal. So, when you call this command:

mvn clean

It will call the pre-clean phase and the clean phase which links to the clean:clean goal.

It is almost the same as:

mvn pre-clean clean:clean

More detail and full examples are in https://www.surasint.com/maven-life-cycle-phase-and-goal-easy-explained/

Answer 7

Maven working terminology having phases and goals.

Phase:Maven phase is a set of action which is associated with 2 or 3 goals

exmaple:- if you run mvn clean

this is the phase will execute the goal mvn clean:clean

Goal:Maven goal bounded with the phase

for reference http://books.sonatype.com/mvnref-book/reference/lifecycle-sect-structure.html

Answer 8

There are following three built-in build lifecycles:

• default
• clean
• site

Lifecycle default -> [validate, initialize, generate-sources, process-sources, generate-resources, process-resources, compile, process-classes, generate-test-sources, process-test-sources, generate-test-resources, process-test-resources, test-compile, process-test-classes, test, prepare-package, package, pre-integration-test, integration-test, post-integration-test, verify, install, deploy]

Lifecycle clean -> [pre-clean, clean, post-clean]

Lifecycle site -> [pre-site, site, post-site, site-deploy]

The flow is sequential, for example, for default lifecycle, it starts with validate , then initialize and so on...

You can check the lifecycle by enabling debug mode of mvn ie, mvn -X <your_goal>

Answer 9

In reference to Pace's answer ,

If you specify a goal when you execute Maven then it will run that goal and only that goal. In other words, if you specify the jar:jar goal it will only run the jar:jar goal to package your code into a jar.

there is an exception to this statement. Maven Plugin API allows a goal to trigger execution of a lifecycle phase.

Consider the following project:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.example</groupId>
  <artifactId>simple-maven-project</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>
</project>

When you execute the goal run defined in spring-boot-maven-plugin

mvn org.springframework.boot:spring-boot-maven-plugin:run

it prints

[INFO] ------------------< org.example:simple-maven-project >------------------
[INFO] Building simple-maven-project 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] >>> spring-boot-maven-plugin:3.0.0:run (default-cli) > test-compile @ simple-maven-project >>>
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ simple-maven-project ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Users\Bartosz\IdeaProjects\simple-maven-project\src\main\resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ simple-maven-project ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ simple-maven-project ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory C:\Users\Bartosz\IdeaProjects\simple-maven-project\src\test\resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ simple-maven-project ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] <<< spring-boot-maven-plugin:3.0.0:run (default-cli) < test-compile @ simple-maven-project <<<
[INFO] 
[INFO] 
[INFO] --- spring-boot-maven-plugin:3.0.0:run (default-cli) @ simple-maven-project ---
[INFO] ------------------------------------------------------------------------

This is because the goal definition in spring-boot-maven-plugin-XXXjar/META-INF/maven/plugin.xml contains <executePhase>test-compile</executePhase> , which executes test-compile and all the preceding phases.

<mojo>
    <goal>run</goal>
    (...)
    <executePhase>test-compile</executePhase>
    (...)
</mojo>

Moreover, because of the default bindings for the "jar" packaging, few other goals are executed. If the packaging is changed to "pom", the same command results with

[INFO] ------------------< org.example:simple-maven-project >------------------
[INFO] Building simple-maven-project 1.0-SNAPSHOT
[INFO] --------------------------------[ pom ]---------------------------------
[INFO] 
[INFO] >>> spring-boot-maven-plugin:3.0.0:run (default-cli) > test-compile @ simple-maven-project >>>
[INFO] 
[INFO] <<< spring-boot-maven-plugin:3.0.0:run (default-cli) < test-compile @ simple-maven-project <<<
[INFO] 
[INFO] 
[INFO] --- spring-boot-maven-plugin:3.0.0:run (default-cli) @ simple-maven-project ---
[INFO] ------------------------------------------------------------------------

because there are no default bindings for test-compile or any previous phase and this packaging type.