Detailed description of the life cycle of the Maven plugin (two)

Plug-in configuration

Definition explanation: Plug-in target

After we get to know the Maven plugin. We found that it is obviously undesirable to write a separate plugin for each function, since there are very many reusable code behind these tasks. So, by aggregating these functions into a plug-in, each function we call a plug-in target.

To give a sample example:

Maven-dependency-plugin has more than 10 targets, each of which corresponds to a function

Analyze Project Dependencies: Dependency:analyze

List Project Dependency trees: Dependency:tree

List all resolved dependencies for the project: Dependency:list

Plug-in global configuration in POM

Some of the values from the creation of the project to the project announcement will not change, or very little change, for such cases, can be in the Pom.xml global configuration.

Example: Configuring a generic Java compilation version number

        <build><plugins><plugin><groupId>org.apache.maven.plugins</groupId>< Artifactid>maven-compiler-plugin</artifactid><version>3.1</version><configuration> <source>1.6</source><target>1.6</target></configuration></plugin></ Plugins></build>

This way, whether the maven-compiler-plugin:compile bound to the compile phase or the Maven-compiler-plugin:testcompiler task is bound to the Test-compiler stage. You can use this configuration to compile based on the Java1.6 version number.

Plug-in task configuration in POM

Get plugin Information

Online plugin Information

source of Maven plugins : Basic all basic maven plugins are from Apache and Codehaus

Since Maven itself belongs to Apache. All it has very many official plugins and they have very good stability

In addition to Apache, the Mojo Project hosted on Codehaus also offers a large number of Maven plugins.

(Note: These plug-ins have relatively poor documentation and reliability and are faulty when used.) Can only view the source code yourself)

Plugin parsing mechanisms and FAQs

Like dependency artifacts, plug-in artifacts are stored in the MAVEN repository in the same coordinates. When needed, MAVEN will look for plugins from the local repository. Assumption does not exist. Lookup from the remote plug-in repository. After you find the plugin, download it to your local repository

Note: Rely on the remote warehouse! = Plugin Remote repository, MAVEN will treat them differently.

The dependency required by Maven is not present in the local repository. Maven will go to configure the remote repository to find

The plugin required by Maven does not exist in the local repository. Maven does not go to these remote repositories for lookups.

How to configure the remote repository for plugins

MAVEN's plugin remote warehouse is configured with <pluginRepositories> and ><pluginRepository>

Maven built-in remote repository configuration for plugins such as the following: It turns off support for snapshot and prevents unstable builds

<pluginrepositories><pluginrepository><id>central</id><name>maven Plugin Repository</name><url>http://repo1.maven.org/maven2</url><layout>default</layout ><snapshots><enabled>false</enabled></snapshots><releases><updatepolicy >never</updatePolicy></releases></pluginRepository></pluginRepositories>

Simple configuration:

1.2 Omit GroupID configuration:

MAVEN provides a simple configuration strategy for its official plugins, Its official GroupID is: Org.apache.maven.plugins, in the configuration can omit the configuration, maven in parsing the plug-in, when the initiative will be the default GroupID. However, this method of use is not recommended under normal circumstances, because only one line of configuration is left. And easy is confusing for beginners.

2. Omit the version number configuration:

Maven's Pom is an inherited mechanism (specifically described in Maven aggregation and inheritance). There is a super Pom in Maven, and all of the projects inherit the Super Pom configuration, so the user does not add any configuration. When Maven uses the core plugin, their version number is determined.

Maven-clean-plugin

Maven-compiler-plugin

Maven-surefire-plugin

Assuming that we do not configure the version number of the plugin at the time of configuration, MAVEN iterates through the local repository and the entire remote plug-in repository, merging the warehouse metadata under that path to calculate the latest and release version numbers.

In Maven2:::: Assume that the version number is not configured. Then the default is resolved to the latest version number. There may be potential problems with this version number, for example. This version number is the snapshot version number

In Maven3::: If you do not configure the version number, then the default is resolved to release version number, which overcomes the stability problem, but there may be potential problems, for example, the behavior of the new version number and the behavior of the old version number has changed, so there will be build failure

So: When using the plugin, the set version number should be displayed.

Ford: All sentient beings are parents. Hundred good filial piety is first.

Clear Heart Buddha Sentient beings three no difference, the same body name Big sad truth. Just know. Caring for others is to care for themselves, save others is to save themselves, good for people, it is good for themselves, and then, sentient beings their parents to save degrees, this is the Buddha's filial piety.

Copyright notice: This article Bo Master original articles, blogs, without consent may not be reproduced.

Detailed description of the life cycle of the Maven plugin (two)