Deep understanding of Maven and applications (1): lifecycle and plug-ins

Maven has been used in the project for almost a year. Recently, it was suddenly found that the maven Project Build in eclipse is very slow, because the clean install command is often used to build the project, and there are not so many problems, however, I have been unable to cope with the same build speed as the tortoise recently. So I am determined to go over Maven practice,
For me, Maven has two main roles: one is the dependency solution function for the jar package, and the other is to manage the jar package by yourself. The other is the project construction, packaging, and deployment. Now I think the most important thing is the maven lifecycle and plug-in mechanism. Let's summarize it.

URL: http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

1. Three sets of lifecycle

For the maven lifecycleThree mutually independent lifecyclesAre 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 Life Cycle contains several stages, which are sequential and later stages depend on the previous stages. For example, the clean life cycle contains three stages: Pre-clean, clean, and post-clean. If the clean stage is executed, the pre-clean stage is executed first.
ComparedThere is a dependency between the two stages. The three lifecycles are independent of each other.You can only call a certain stage of the clean lifecycle, or directly execute a certain stage of the default lifecycle without executing the clean cycle.

2. Clean Lifecycle

The Clean lifecycle consists of three phases:

Pre-clean	Executes Processes needed prior to the actual project cleaning
Clean	Remove all files generated by the previous build
Post-clean	Executes processes needed to finalize the project cleaning

3. Default Lifecycle

The default Life Cycle defines all the steps to be performed during a real build, including the following phases:

Validate	Validate the project is correct and all necessary information is available.
Initialize	Initialize build state, e.g. Set Properties or create directories.
Generate-Sources	Generate any source code for compression sion in compilation.
Process-Sources	Process the source code, for example to filter any values.
Generate-Resources	Generate resources for future sion in the package.
Process-Resources	Copy and process the resources into the destination directory, ready for packaging.
Compile	Compile the source code of the project.
Process-classes	Post-process the generated files from compilation, for example to do bytecode enhancement on Java classes.
Generate-test-Sources	Generate any test source code for compression sion in compilation.
Process-test-Sources	Process the test source code, for example to filter any values.
Generate-test-Resources	Create resources for testing.
Process-test-Resources	Copy and process the resources into the test destination directory.
Test-compile	Compile the test source code into the test destination directory
Process-test-classes	Post-process the generated files from test compilation, for example to do bytecode enhancement on Java classes. For Maven 2.0.5 and above.
Test	Run tests using a suitable unit testing framework. These tests shoshould not require the code be packaged or deployed.
Prepare-Package	Perform any operations necessary to prepare a package before the actual packaging. This often results in an unpacked, processed version of the package. (Maven 2.1 and above)
Package	Take the compiled code and package it in its distributable format, such as a jar.
Pre-integration-test	Perform actions required before integration tests are executed. This may involve things such as setting up the required environment.
Integration-test	Process and deploy the package if necessary into an environment where integration tests can be run.
Post-integration-test	Perform actions required after integration tests have been executed. This may including cleaning up the environment.
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.

 

4. Site Lifecycle

The purpose of the SIET 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 stages are as follows:

Pre-site	Executes Processes needed prior to the actual project site generation
Site	Generates the project's site Documentation
Post-site	Executes processes needed to finalize the site generation, and to prepare for site deployment
Site-deploy	Deploys the generated site documentation to the specified Web Server

5. Command Line and lifecycle

The main way to execute Maven tasks from the command line is to call the maven lifecycle stage.. Note that,Each lifecycle is independent of each other, and a lifecycle stage is dependent on each other.. Example:
1. $ MVN clean: This command calls the clean stage of the clean lifecycle. The actual execution phase is the pre-clean and clean stages of the clean lifecycle.
2. $ MVN test: This command calls the test stage of the default lifecycle. The actual call is the default life cycle such as validate and initialize until all stages of test.
3. $ MVN clean install: this command is used to replace the clean and default instal stages of the clean lifecycle.

6. Plug-in objectives

The core of Maven only defines the abstract life cycle. A specific task is completed by the plug-in, and the plug-in exists independently.
To reuse code, a plug-in can often complete multiple tasks. For example, Maven-dependency-plugin has more than 10 targets, each of which corresponds to a function, such as dependency: analyze, dependency: Tree, and dependency: list. This is a common method. The prefix of the plug-in is before the colon, and the target of the plug-in is later.

7. Plug-in 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, and a specific build task has been completed. For example, the project compilation task corresponds to the compile phase of the default lifecycle, and the compile target of the maven-compiler-plugin plug-in can complete the task, so they are bound.

7.1 Built-in binding

Maven binds many plug-ins to the core of some major lifecycles, as follows:
The life cycle of clean and site is relatively simple.

Clean

Clean: clean

Site	Site: Site
Site-deploy	Site: deploy

The binding relationship between the default lifecycle and the plug-in target is somewhat complicated. This is because for any project, such as the jar project and War Project, their project cleanup is the same as the site generation task, but the build process is different. For example, a jar project needs to be converted into a jar package, while a war project needs to be converted into a war package.
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 in pom. The most common packaging type is jar, which is also the default packaging type.. Based on the package type, the default lifecycle has the following built-in binding relationships:

Process-Resources	Resources: Resources
Compile	Compiler: Compile
Process-test-Resources	Resources: testresources
Test-compile	Compiler: testcompile
Test	Surefire: Test
Package	EJB: EJB Or Ejb3: ejb3 Or Jar: jar Or Par: par Or RAR: RAR OrWar: War
Install	Install: Install
Deploy	Deploy: deploy

 

7. 2 custom binding

In addition to built-in binding, users can also select a plug-in target to bind to a certain stage of the lifecycle to execute more and more special tasks.

<! -- Automatically copy the resource file to the root directory --> <plugin> <groupid> Org. apache. maven. plugins </groupid> <artifactid> Maven-resources-plugin </artifactid> <version> 2.6 </version> <configuration> <includeemptydirs> true </includeemptydirs> <encoding> GBK </encoding> <nonfilteredfileextensions> <strong> EXE </nonfilteredfileextension> <nonfilteredfileextension> zip </strong> <strong> vbs </nonfilteredfileextension> <strong> Sh </strong> </nonfilteredfileextensions> </configuration> <executions> <execution> <ID> copy-resources </ID> <phase> validate </phase> <goals> <goal> copy-Resources </goal> </goals> <configuration> <shortdeemptydirs> true </shortdeemptydirs> <outputdirectory >$ {project. build. directory} </outputdirectory> <excludes> <exclude> agentmanager. jsmooth </exclude> <exclude> assembly. XML </exclude> </Excludes> <resources> <resource> <directory> src/main/resources/</directory> <filtering> true </filtering> </resource> </resources> </configuration> </execution> </executions> </plugin>

For example, if a task with the ID of copy-resources is defined and bound to the validate stage of the default lifecycle, the bound plug-in is Maven-resources-plugin, And the plug-in target is copy-resources. The copy-resources function of the plug-in is used to copy project resource files.

<! -- Automatically copy the maven dependency package to the lib directory --> <plugin> <groupid> Org. apache. maven. plugins </groupid> <artifactid> Maven-dependency-plugin </artifactid> <version> 2.1 </version> <executions> <execution> <ID> copy </ID> <phase> install </phase> <goals> <goal> copy-dependencies </goal> </goals> <configuration> <outputdirectory> lib </outputdirectory> </configuration> </execution> </executions> </plugin>

Same as above, a copy-ID task is defined, and the copy-dependencies target of the plug-in Maven-dependency-plugin is bound to the install stage of the default life cycle, to automatically copy jar packages that the project depends on.

When a plug-in target is bound to a different life cycle stage, the execution sequence is determined by the sequence of life cycle stages. If multiple targets are bound to the same stage, their execution sequence is determined by the order stated by the plug-in..

8. Plug-in configuration

You can configure the parameters of the plug-in target to further adjust the tasks executed by the plug-in target.

8. 1. Command Line plug-in configuration

For example, if $ MVN install-dmaven. Test. Skip = true, the test step is skipped.
The Java built-in function of parameter-D is to set a Java System attribute through the command line. MAVEN simply re-uses this parameter to configure plug-in parameters.

8. 2. Global configuration of the plug-in POM

For example, if the source file of version 1.6 is used for project compilation, A bytecode file compatible with jvm1.6 is generated, as follows:

<plugin><groupId>org.apache.maven.plugins</groupId><artifactId>maven-compiler-plugin</artifactId><version>2.3.2</version><configuration><source>1.6</source><target>1.6</target></configuration></plugin>

 

9. Get the plug-in description

$ MVN help: Describe-dplugin = org. Apache. Maven. plugins: Maven-compiler-plugin: 2.1 to get the details of the plug-in.
It can be simplified:
$ MVN help: Describe-dplugin = Compiler
If you only describe the information of the plug-in target, you can add the goal parameter:
$ MVN help: Describe-dplugin = compiler-dgoal = compile
If you want to output more detailed information, you can add the detail parameter:
$ MVN help: Describe-dplugin = compiler-ddetail