Maven-dependency and plug-in management

Maven-dependency and plug-in management
1. Dependency Management

Not all dependencies configured in the parent POM can be used in different child classes, or used but not a uniform version. To solve this problem, define the dependency information in the parent POM label introduce dependencies in POM. The details are as follows: configure the dependencies used in the project in the parent POM, but are no longer configured in the dependency label, because this label can be automatically inherited, the dependencyManagement label is used, and the dependency defined in this label is not quilt POM is automatically introduced and must use the dependency declaration in the subclass. Sometimes it may be okay to directly reference the dependency in the sub-POM? One is unified management, and the other is simplified configuration. Dependency Management:

A) configure the dependency management to be introduced in the parent POM -- pom. xml in scattered-items:

<Properties> <junit. version> 4.1 </junit. version> </properties> <dependencyManagement> <dependencies> <dependency> <groupId> junit </groupId> <artifactId> junit </artifactId> <version >$ {junit. version }</version> <scope> test </scope> </dependency> </dependencies> </dependencyManagement>

The properties label is used to define global variables, define variable meanings in Java, and extract repeated values.

B) configure POM. xml in dependency -- items-thkinjava in the sub-pom:

<Dependencies> <dependency> <groupId> junit </groupId> <artifactId> junit </artifactId> </dependency> </dependencies>

In the sub-POM, you only need to configure the groupId and artifactId for the introduction of junit dependencies. You do not need to specify either the version or scope.

Note: the key point is that the dependency configured in the dependencyManagement label in the parent POM is not automatically introduced into the Child project, that is, although dependencyManagement in the parent POM defines the dependency of junit, if the child class does not have the <dependency> of junit does not introduce the junit dependencies of child classes. If the child project does not want to use junit of version 4.1, you can specify the junit version you want to use. overwrite the definition of junit in the parent POM, that is, the junit definition in the parent POM has nothing to do with it. This flexibility is enough to meet our daily needs.

It is recommended that dependencies be placed in parent POM dependencyManagement. One is to reduce configuration and the other is to facilitate management. For example, version conflict is a common problem. Use dependencyManagement + variables for unified management, which is safer and more efficient.

One type of dependency scope is import, which is effective only under the dependencyManagement element. The dependency using this scope usually points to a POM, which is used to import and merge the dependencyManagement configuration in the target POM in the dependencyManagement element of the current POM. For example, if you want to use the dependencyManagement configuration configured above in another module, you can also use the import range dependency to import the configured dependency in addition to replication inheritance:

<DependencyManagement> <dependencies> <dependency> <groupId> org. andy. items </groupId> <artifactId> scattered-items </artifactId> <type> pom </type> <version> 1.0-SNAPSHOT </version> <scope> import </scope> </dependency> <groupId> othergi </groupId> <artifactId> otherai </artifactId> <version >$ {other. version }</version> </dependency> </dependencies> </dependencyManagement>

3. Plug-in management

The principles of plug-in management and dependency management are the same. Different elements are defined differently. Plug-in management labels are the sub-tag pluginManagement of build tags, defined in parent POM, and referenced by sub-POM. If you have a plug-in that generates the source code package and uses the plug-in for management, the configuration process is as follows:

A) POM. xml in parent pom -- scattered-items:

<Build> <pluginManagement> <plugins> <plugin> <groupId> org. apache. maven. plugins </groupId> <artifactId> maven-source-plugin </artifactId> <version >$ {sources. plugin. verion} </version> <executions> <execution> <id> attach-sources </id> <phase> verify </phase> <goals> <goal> jar-no- fork </goal> </goals> </execution> </executions> </plugin> <groupId> org. apache. maven. plugins </groupId> <artifactId> maven-compiler-plugin </artifactId> <version> 3.1 </version> <configuration> <source> 1.7 </source> <target> 1.7 </target> </configuration> </plugin> </plugins> </pluginManagement> </build>

B) POM. xml in sub-pom -- items-thkinjava:

<Build> <plugins> <plugin> <groupId> org. apache. maven. plugins </groupId> <artifactId> maven-source-plugin </artifactId> </plugin> </plugins> </build>

It is similar to dependency management, but it is replaced with plug-in management.

4. Conventions are better than configurations

There is no need to emphasize the importance of standards. ConventionOver Configuration is one of the core design concepts of maven.

Any maven project implicitly inherits the super POM, a bit similar to all Java classes inherit the Object class, so a large number of Super POM configurations will be inherited by all maven projects, these configurations it has become an agreement advocated by maven.

Super POM location: $ M2_HOME/lib/maven-model-builder-x.x.x.jar under the org/apache/maven/model/pom-4.0.0.xml path.

Maven-dependency and plug-in management