Detailed explanation of Maven's life cycle

This article focuses on these issues:

What are the stages of maven's life cycle?
What is the relationship between maven's life cycle and plug-in down?
How are plugins and plugin goals related?
If we want to use a certain plug-in, how to find it on the official website?
How to call the plugin manually?

1. Life cycle (clean+site+default)

Before the emergence of Maven, the life cycle of project construction already existed. Developers clean up, compile, test and deploy projects every day. However, due to the lack of uniform specifications, different companies and even different projects have different construction methods all the same.

Maven learns and reflects from a large number of projects and construction tools, and finally summarizes a set of highly perfect and easy-to-extend life cycles. This life cycle abstracts and unifies almost all construction processes of the project, such as cleaning, initialization, compilation, testing, packaging, integration testing, verification, deployment, and site generation.

1. The relationship between life cycle and plug-in

Maven 生命周期是抽象的，其本身不能做任何实际工作，这些实际工作（如源代码编译）都通过调用 Maven 插件中的插件目标（plugin goal）完成的。

In order to better understand the relationship between the Maven life cycle, plug-ins, and plug-in goals, we can 将 Maven 生命周期理解成一个抽象父类, 将插件理解成其子类, 将插件目标理解成子类中重写的方法, whose basic structure is similar to the sample code below.

/**
* 模拟 maven 生命周期
*/
public abstract class LifeCycle {
    
    
    //定义构建过程
    public void build() {
    
    
        //模拟生命周期各个阶段，即调用插件中目标
        clean();
        initialize();
        compile();
        packager();
        install();
    }

    //定义清理的过程
    public abstract void clean();

    //定义初始化的过程
    public abstract void initialize();

    //定义编译的过程
    public abstract void compile();

    //定义打包的过程
    public abstract void packager();

    //定义安装的过程
    public abstract void install();
}

Simulate the subclass of the clean plugin, the code is as follows.

/**
* 子类模拟clean 相关的插件
*/
public abstract class CleanPlugin extends LifeCycle {
    
    
    //重写父类（生命周期）的清理工作
    //模拟插件目标
    @Override
    public void clean() {
    
    
        System.out.println("清理");
    }
}

In the above example, the parent class LifeCycle simulates the Maven life cycle, the subclass CleanPlugin simulates the Maven plug-in, and the rewritten clean() in the subclass simulates the plug-in goal. The original intention of the plug-in is pluggable, you can use it to add or not to add it.

Although the code in the examples is far from the actual Maven code, the basic idea is the same approach. The life cycle abstracts the various steps of construction and defines their execution order, but does not provide a specific implementation. The implementation of the construction process is completed in the plug-in. If you want to complete a certain construction step,调用插件中的一个或多个插件目标即可。

2. Three life cycles of maven

Maven's life cycle is not only one, but three sets, 并且这三套生命周期之间是没有关系的. A set of life cycle contains many different stages, these different stages are in order, and some stages must be completed after a certain stage before proceeding. Maven's three sets of life cycles are: clean (cleaning), default (default), site (site). Next, we will introduce these three life cycles one by one.

clean: used to clean up the project, the clean life cycle includes the following three stages:

pre-clean: preparations before cleaning;
clean: clean up the results of the previous build;
post-clean: The work that needs to be done after cleaning.

default: The default life cycle defines all the steps required for the actual construction of the project, and it is the core and most important part of all life cycles.

The default life cycle contains many stages, as shown in the following table:

site: The purpose of the sit life cycle is to build and deploy the project site. Maven can automatically generate a friendly site based on the information contained in the POM, which contains some documents related to the project.

The site life cycle consists of the following 4 phases:

pre-site: preparation stage. The work that needs to be done before generating the site;
site: generate site stage;
post-site: end stage. The work that needs to be done after the site is generated;
site-deploy: Release stage. We can publish the site generated above to the corresponding server.

3. Life cycle execution rules

Each set of life cycle contains a series of construction phases (phase), these phases are sequential, and the latter phase depends on the previous phase. The most direct way for a user to interact with Maven is to invoke these lifecycle phases.

Taking the clean life cycle as an example, it includes three stages: pre-clean, clean and post-clean. When the user calls the pre-clean stage, only the pre-clean stage is executed; when the user calls the clean stage, the pre-clean and post-clean stages are executed. The clean phase will be executed. When the user invokes the post-clean phase, the three phases of pre-clean, clean and post-clean will be executed.

三套生命周期本身是相互独立的，用户可以只调用 clean 生命周期的某个阶段，也可以只调用 default 生命周期的某个阶段，而不会对其他生命周期造成任何影响。当然也可以同时调用两套生命周期的某个阶段。

By passing the phase name to the mvn command, you can call the build phase, for example:
mvn clean, which is to call the clean phase of the clean life cycle, and the target directory of the current project will be cleared.

Let's try to execute Maven's packaging command: mvn package -DskipTests(-DskipTests means to skip the test. If you don't skip the test, it will automatically execute the method with @Test annotation in the project test directory when packaging). It is to call the package phase of the default life cycle. After the execution is completed, you can see the life cycle it has passed. Therefore, when we want to build the project, we don't need to execute the stages before the package stage separately, but Maven automatically executes it for us. Suddenly found that building the project is so simple and convenient.

生命周期中的每个构建过程都可以绑定一个或多个插件目标, and Maven bundles default plugins for most build steps. For example, the plug-in for source code compilation is maven-compiler-plugin, the plug-in for integration testing is maven-surefire-plugin, etc. (more on this later).

At the same time, we can also execute two sets of life cycles, such as calling the clean phase of the clean life cycle plus the package phase of the default life cycle:mvn clean package -DskipTests

2. Maven plugin (plugin)

1. Two types of plugins

Maven 实际上是一个依赖插件执行的框架, every task it performs is actually done by a plugin. The packages produced by Maven do not contain any Maven plug-ins, they exist in the form of independent components, and will be downloaded from the warehouse only when Maven needs to use a certain plug-in.

As shown in the table below, Maven provides the following two types of plugins:

2. There are two ways to call the plug-in

Plug-in goal: For Maven plug-ins, in order to improve code reusability, usually a Maven plug-in can implement multiple functions, and each function is a plug-in goal, that is, a Maven plug-in is a collection of plug-in goals. We can understand the plug-in as a class, and the plug-in target is the method in the class, and the corresponding function can be realized by calling the plug-in target.

Two ways to use:

Introduce it into the project, then bind the plug-in to the specified life cycle, and then execute the life cycle command to automatically call the plug-in, for example:mvn clean、mvn install
The plugin can be called directly by the following command.
- Use the Maven command to execute the goal of the plug-in, the syntax is as follows:mvn [插件名]:[目标名]
- For example, to call the compile goal of the maven-compiler-plugin plugin, the command is as follows: mvn compiler:compile(note that the full name of the plugin cannot be used, it must be an abbreviated name, otherwise it will report that the plugin cannot be found)

Plug-in binding: In order to complete a specific build task, Maven 生命周期的阶段需要和 Maven 插件的目标相互绑定. For example, the code compilation task corresponds to the compile phase of the default life cycle, and the compile goal of the maven-compiler-plugin plug-in can complete this task, so binding them can achieve the purpose of code compilation.

3. Built-in binding

By default, Maven binds plug-in goals for some core life cycle phases. When users invoke these phases, the corresponding plug-in goals will automatically perform corresponding tasks.

In the table, the default life cycle only lists the phases that are bound to the plug-in target. It has many other phases, but these phases are not bound to any plug-in target by default, so they do not have any actual behavior.

insert image description here

We can directly execute the Maven command to see which plugin goals are included in the build process. For example, if you execute the command in the Maven project mvn clean install, you can see the following output, and the marked part in the figure is the plug-in target that is invoked when executing this command.

Like these built-in binding plug-ins, we can also display the declaration in the project and then modify the configuration. At this time, the default configuration of the built-in binding plug-ins will be overwritten!

4. Custom binding plug-in

In addition to the built-in binding, users can also choose to bind a plug-in goal to a certain stage of the Maven life cycle. This binding method is custom binding. Custom bindings allow Maven to perform more and richer tasks during the build process.

maven-antrun-plugin插件的run 目标For example, if we want to display custom text information in the clean phase of the clean life cycle, we only need to bind to the phase through the sub-element plugins of the build element in the project's POM, and use the plugin to output the cleancustom Text information will do.

<build>
	<plugins>
        <!-- 绑定插件 maven-antrun-plugin -->
        <plugin>
              <groupId>org.apache.maven.plugins</groupId>
              <artifactId>maven-antrun-plugin</artifactId>
              <version>3.0.0</version>
              <executions>
                  <execution>
                    <!--自定义 id -->
                    <id>custom clean</id>
                    <!--插件目标绑定的构建阶段 -->
                    <phase>clean</phase>
                    <!--插件目标 -->
                    <goals>
                    	<goal>run</goal>
                    </goals>
                    <!--配置 -->
                    <configuration>
                      	<!-- 执行的任务 -->
                    	<target>
                        	<!--自定义文本信息 -->
                        	<echo message="清理阶段"/>
                      </target>
                    </configuration>
                  </execution>
              </executions>
          </plugin>
	</plugins>
</build>

In addition to the coordinate information of the plug-in, the above configuration also defines some execution configurations through the executions element. Each executein sub-element under executions can be used to configure the execution of a task. The meanings of each element under execution are as follows:

id: the unique identifier of the task.
phase: The lifecycle phase that the plugin target needs to bind to.
goals: It is used to specify a set of plug-in goals, and its child element goal is used to specify a plug-in goal.
configuration: The configuration of the task, its sub-element tasks is used to specify the tasks to be executed by the plug-in target.

Execute the command mvn clean, the result is as follows:

Above we just simply use the run target of the maven-antrun-plugin plug-in to bind to the clean phase and print a paragraph of text. In fact, we can also use this plug-in to complete some special tasks, such as automatically uploading the package to the specified location after packaging, etc... I won't go into details here.

Running order of plug-ins: When plug-in targets are bound to different phases of the life cycle, their execution order is determined by the sequence of life cycle phases. If multiple targets are bound to the same life cycle phase, their execution order is consistent with the order of plugin declarations, the ones declared first are executed first, and the ones declared later are executed later.