What is lifecycle:Maven's lifecycle is to abstract and unify all the building processes. Maven learns from and reflects on a large number of projects and build tools, and then summarizes a set of highly complete and scalable lifecycles. This lifecycle includes almost all of the building steps for the project, such as cleaning, initialization, compilation, testing, packaging, integration testing, verification, deployment, and site generation. That is to say, almost all project builds can be mapped to such a lifecycle. Maven's lifecycle is abstract, which means that the lifecycle itself does not actually work. In Maven's design, actual tasks (such as compiling Source Code) are completed by the plug-in. This idea is very similar to the template method in the design pattern. One or more plug-ins can be bound to each build step. MAVEN writes and binds the default plug-ins for most build steps. When users have special needs, you can also configure the plug-in to customize the build behavior, or even write the plug-in yourself.
Detailed description of lifecycle:
Three sets of lifecycle:Maven has three sets of independent lifecycles: clean, default, and site. The purpose of the clean life cycle is to clean up the project, the default life cycle is to build the project, and the site life cycle is to build the project site. Each lifecycle contains several stages, which are ordered and dependent on the previous stages. The most direct interaction between users and Maven is to call these stages. Compared with the dependency between the two stages, the three lifecycles are independent of each other.
Clean lifecycle:The purpose of the clean life cycle is to clean up the project, which contains three phases:
- Pre-clean: perform the work that needs to be completed before cleaning.
- Clean: clears the last build generated file
- Post-clean
Default lifecycle:
- Validate
- Initialize
- Generate-Source
- Process-Sources: process the Project Master resource file. In general, it is to replace the variables in the src/main/Resource Directory and copy them to the main classpath directory of the project output.
- Generate-Resources
- Process-Resources
- Compile: Compile the source code of the Project. Generally, compile the java files under the src/main/Java directory to the main classpath directory of the project output.
- Process-classes
- Generate-test-Sources
- Process-test-Sources: process the project test resource file. In general, it is to replace the variables in the src/test/Resource Directory and copy them to the main classpath directory of the project output.
- Generate-test-Resources
- Process-test-Resources
- Test-compile: Compile the test code of the project. In general, it is to compile the java files under the src/test/Java directory to the test classpath directory of the project output.
- Process-test-classes
- Test: run the test using the unit test framework. The test code is not packaged or deployed.
- Prepare-Package
- Package: accept compiled code and package it into a releasable version, such as jar
- Pre-integration-test
- Integration-test
- Post-integration-test
- Verify
- Install: Install the package to the maven local repository for use by other local Maven projects.
- Deploy: Copies the final package to a remote repository for use by other developers and Maven projects.
Site lifecycle:The purpose of the site lifecycle is to establish and release a project site. Maven can automatically generate a friendly site based on the information contained in POM to facilitate team communication and release of project information. The lifecycle includes the following phases:
- Pre-site: execute some work that needs to be done before the project site is generated
- Site: generate project site Documentation
- Post-site: execute some work that needs to be completed after the project site is generated
- Site-deploy: Release the generated project site to the server.
Command Line and lifecycle:The main way to execute Maven tasks from the command line is to call the maven lifecycle stage. The following describes the lifecycle of a Maven command:
- $ MVN clean: This command calls the clean stage of the clean lifecycle. The actual execution phase is the pre-clean and clean phases of the clean lifecycle.
- $ MVN test: This command calls the test stage of the default lifecycle. The actual execution phase is the default life cycle's validate, initialize, etc. All stages of test are known. This explains why the project code can be automatically compiled during the test.
- $ MVN clean install: This command calls the clean stage of the clean lifecycle and the install stage of the default lifecycle. The actual execution phase is the pre-clean and clean phases of the clean life cycle, and all stages of the default life cycle from validate to install. This command combines two lifecycles. It is a good practice to clear a project before executing a real project build.
- $ MVN clean deploy site-deploy: This command calls the clean stage of the clean lifecycle, default deploy stage of the lifecycle, and site-deploy cycle of the site lifecycle. The actual execution phase is the pre-clean and clean stages of the clean life cycle, all stages of the default life cycle, and all stages of the site life cycle. This command combines all three life cycles of Maven, and deploy is the last stage of the default life cycle. Site-deploy is the last stage of the site life cycle.
Plug-in goals:To reuse code, a plug-in can often complete multiple tasks. For example, Maven-dependency-plugin can do many things based on project dependencies. It can analyze project dependencies and help identify potential useless dependencies. It can list project dependency trees and help analyze dependency sources. It can list all resolved dependencies of a project, and so on. Writing an independent plug-in for each of these features is obviously not desirable, because there is a lot of code behind these tasks that can be reused, so these features are gathered in a plug-in, each function is a plug-in target. Maven-dependency-plugin has more than a dozen targets, each of which corresponds to a function. The plug-in targets mentioned in the appeal are dependency: analyze, dependency: Tree, and dependency: list.
Plugin binding:The Maven lifecycle is bound with the plug-in to complete the actual build task. Specifically, the lifecycle phase is bound with the plug-in target to complete a specific build task. For example, the project compilation task corresponds to the compile phase of the default lifecycle, and the compile target of the maven-compile-plugin plug-in can complete the task.
Built-in binding:Maven binds many plug-in targets for some core lifecycles. When you call the lifecycle stage through a command line, the corresponding plug-in targets will execute the corresponding tasks. The binding relationship between the clean lifecycle stage and the plug-in target:
| Lifecycle stage |
Plug-in objectives |
Pre-clean
Clean
Post-clean |
Maven-clean-plugin: clean |
The binding relationship between the site lifecycle stage and the plug-in target:
| Lifecycle stage |
Plug-in objectives |
Pre-site
Site
Post-site
Site-deploy |
Maven-site-plugin: Site
Maven-site-plugin: deploy |
Compared with the clean and site lifecycles, the binding relationship between default lifecycles and plug-in targets is more complex. Because the packaging type of the project affects the construction process, the binding relationship between the phase of the default lifecycle and the plug-in target is determined by the Project packaging type, the packaging type is defined by the packaging element. The most common and important packaging type is jar, which is also the default packaging type. For a project of this packaging type, the built-in plug-in binding relationship and specific tasks of its default lifecycle are as follows:
| Lifecycle stage |
Plug-in objectives |
Process-Resources
Compile
Process-test-Resources
Test-compile
Test
Package
Install
Deploy |
Maven-resources-plugin: Resources
Maven-compiler-plugin: Compile
Maven-resources-plugin: testresourcesmaven-compiler-plugin: testcompilemaven-surefire-plugin: teaven Aven-jar-plugin: jarmaven-intall-plugin: installmaven-deploy-plugin: deploy |
In addition to the default packaging type jar, common packaging types include war, pom, Maven-plugin, and ear.
Custom binding:In addition to built-in binding, you can also choose to bind a plug-in target to a certain stage of the lifecycle. A common example is to create the project's source code jar package. This task is not involved in the built-in plug-in binding relationship, so you need to configure it yourself. Maven-source-plugin can help us complete this task. Its jar-no-fork target can package the main code of the project into a jar file, you can bind it to the verify phase of the default life cycle, and create the source code jar package after the integration test is executed and before the component is installed.
<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-source-plugin</artifactId> <version>2.1.1</version> <executions> <execution> <id>attach-sources</id> <phase>verify</phase> <goals> <goal>jar-no-fork</goal> <goals> <execution> <executions> <plugin> <plugins><build>
In the plug-in execution configuration, each execution sub-element in executions can be used to configure and execute a task. In this example, a task with the ID of attach-sources is configured. It is bound to the verify life cycle stage through phase configuration, and the plug-in target to be executed is specified through goals configuration. Sometimes, even if you do not configure the lifecycle stage through the phase element, the plug-in target can be bound to the lifecycle. This is because many plug-ins have defined the default binding stage during compilation. You can use Maven-help-plugin to view the plug-in details and learn about the default binding stage of the plug-in target. Run the following command: $ MVN help: Describe-dplugin = org. apache. maven. plugins: Maven-source-plugin: 2.1.1-ddetail when the plug-in target is bound to different life cycle stages, the execution sequence is determined by the order of the life cycle stages. When multiple plug-in targets are bound to the same stage, the order of these plug-ins determines the execution sequence of the targets.
Plug-in Configuration:You can configure the parameters of the plug-in target to further adjust the tasks executed by the plug-in target to meet the needs of the project.
Command Line plug-in Configuration:Parameters of many plug-ins can be configured from the command line. You can use the-D parameter in the maven command, which is accompanied by a parameter key = parameter value, to configure the parameters of the plug-in target. For example, Maven-surefire-plugin provides a maven. Test. Skip parameter. If its value is true, the test is skipped. Therefore, when running the command, add the following-D parameter to skip the test: $ MVN install-dmaven. Test. Skip = true
Global configuration of the plug-in POM:Not all plug-in parameters are suitable for command line configuration. Some parameter values are not changed, or are rarely changed, from project creation to project release. In this case, one-time configuration in the POM file is obviously easier than repeated command line input. For example, we usually need to configure Maven-compiler-plugin to tell it to compile the source file of Java 1.5 and generate a bytecode file compatible with JVM 1.5. The Code is as follows:
<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.1</version> <configuration> <source>1.5</source> <target>1.5</target> </configuration> <plugin> <plugins><build>
Plug-in task configuration in POM: In addition to configuring global parameters for the plug-in, you can also configure specific parameters for a task. Taking Maven-antrun-plugin as an example, it has a target run that can be used to call ant tasks in Maven. You can bind Maven-antrun-plugin: Run to multiple lifecycle stages, and add different configurations to allow Maven to execute different tasks in different lifecycles, the Code is as follows:
<build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-antrun-plugin</artifactId> <version>1.3</version> <executions> <execution> <id>ant-validate</id> <phase>validate</phase> <goals> <goal>run</goal> <goals> <configuration> <tasks> <echo>I'm bound to validate phase.</echo> </tasks> </configuration> <execution> <execution> <id>ant-verify</id> <phase>verify</phase> <goals> <goal>run</goal> <goals> <configuration> <tasks> <echo>I'm bound to verify phase.</echo> </tasks> </configuration> <execution> <executions> <plugin> <plugins><build>
The configuration element in the global configuration of the plug-in is located under the plugin element, and the configration element is located under the execution element, indicating that this is the configuration of a specific task, not the overall configuration of the plug-in. This Ant-validate task is configured with an echo ant task, which outputs a text to the command line, indicating that the task is bound to the validate stage. The ID of the second task is Ant-verify, which is bound to the verify stage. Similarly, it outputs a piece of text to the command line, telling the task to be bound to the verify stage.
Maven learning notes (6): lifecycle and plug-ins
