Maven Interpretation: How Project-dependent management optimizes

GitHub address : Https://github.com/zwjlpeng/Maven_Detail

The biggest benefit of maven is its strong dependency management system, which specifies the coordinates of the Jar packages required for the project in the Pom configuration file,maven can automatically help us to download from the central warehouse or from the own, when the project due to the transfer of dependency, the introduction of two of the same jar package,Maven will be based on the rules such as the shortest path, the first declarator to the same jar package for the purpose of keeping only one jar package in the project Classpath, we do not queue up some careless programmers, in the same Pom configuration file for the same Jar wrote two different versions of the dependency, Even if this is the case,Maven can be a perfect solution, do not believe you try ~ ~

That is, Maven is the perfect solution to the project's dependencies, so why do we need to optimize the dependencies of the project? The reason is probably as follows

1. When a project relies on a third-party jar package, and this third-party jar package gives us a lot of indirection, this indirect dependency not only wastes disk space, but also potentially conflicts, So we need to exclude these unwanted dependencies from the project, and then we need to optimize the Pom , or the jar package version is too low for indirect dependency, and these lower versions of the jar package are not enough to meet the needs of our project. At this point we also need to exclude these lower versions of the jar package, as follows is an example:

<dependency>    <groupId>net.sf.spring-json</groupId>    <artifactId>spring-json< /artifactid>    <version>1.3.1</version></dependency>

When we introduce Spring-json through MAVEN dependencies in our project, this dependency will bring us cglib-full and the lower version of spring, which can be excluded from the project classpath by simply changing the configuration to the following

<dependency><groupid>net.sf.spring-json</groupid><artifactid>spring-json</ Artifactid><version>1.3.1</version><exclusions><exclusion><groupid> Org.springframework</groupid><artifactid>spring</artifactid></exclusion><exclusion ><groupid>cglib</groupid><artifactid>cglib-full</artifactid></exclusion></ Exclusions></dependency>

Through the exclusion node, you can disconnect the transitive dependency on a jar package, and if you want to disconnect all of the transitive dependencies of a jar package, you can configure

<dependency><groupid>net.sf.spring-json</groupid><artifactid>spring-json</ artifactid><version>1.3.1</version><exclusions><exclusion><groupid>*</ Groupid><artifactid>*</artifactid></exclusion></exclusions></dependency>

2. In multi-module projects, when we define the module dependent Jar separately in the respective module's configuration file, the dependencies between the modules are completely independent, it is possible that the module A and module B depends on the spring version is completely different, one day, We need to upgrade the Spring version of these two projects only to find that we have to change the configuration file for module A and Module B two projects, and when the number of modules is few, we can also do it! But when the number of modules is more ..., hehe! Then we need to optimize the dependencies of the project, as an example,

Project configuration prior to optimization

Module A

<dependency>    <groupId>redis.clients</groupId>    <artifactid>jedis</artifactid >    <version>2.6.  1</version></dependency>

Module B

<dependency>    <groupId>redis.clients</groupId>    <artifactid>jedis</artifactid >    <version>2.4.  0</version></dependency>

module A and Module B depend on the Jedis version is completely different, when we need to upgrade, only one change, then why not a unified way, the implementation of a change in a place, module A and Module B dependent version of the automatic change, yes,Maven Give us this, that's dependencymanagement .

The difference between dependencymanagement and dependencies nodes

Maven has the idea of object-oriented, the three elements of object-oriented is polymorphism, inheritance, encapsulation, dependencies and dependencymanagement is related to the idea of inheritance, in the multi-module project, we have some dependencies, Need to use in every module, if in each module we will reuse the dependencies are written again, as a pursuit of the perfect programmer, you can bear it ..., and I can only hehe ..., so the Pom has the concept of inheritance, in our parent module of the In Pom , the dependencies required for each submodule are defined in the Dependencies node, and only the parent module is inherited to obtain the dependency, and the inherited configuration code is as follows:

<modelVersion>4.0.0</modelVersion><parent><groupId>com.test</groupId>< Artifactid>ecom_airticket</artifactid><version>1.0</version></parent><artifactid >ecom_airticket_online</artifactid><packaging>war</packaging><name>ecom_airticket_ Online</name>

For example, in a multi-module project, each module typically requires a JUnit test jar package, so in the parent pom configuration file, we can write this dependency to

<dependencies><dependency><groupid>junit</groupid><artifactid>junit</ Artifactid><version>${junit.version}</version><scope>test</scope></dependency ></dependencies>

In this way, any inheritance of the Pom file will include the Junit.jar package in the classpath.

Think again, there are some dependencies, is unique to each sub-module, if the parent module is defined in the POM, then all inherited the parent module of the child module will have this dependency, the result is, there are a large number of redundant jar package, not only wasted the disk, but also not conducive to management, then someone said, I define each module's dependent jar package in the respective pom file, good idea!, but think about it, if the A and B sub-modules are dependent on a third-party jar package, then if you want to upgrade the third-party jar package, you need to change the pom files in a and B two modules, which one day, Accidentally, you only changed the A module, and forgot the B module, and then sent the project to the line, the consequences ..., and then imagine, if there are many modules in the project that rely on the same third-party jar package, who can remember the letter to change what?

As a dependencymanagement, MAVEN provides us with a dependency that is defined in the Dependencymanagement node and will not be inherited, so what does it do?

The answer is that dependencymanagement can uniformly manage the version numbers that are dependent on the multi-module project, allowing us to reference a dependency in a subproject without explicitly listing the version number, and Maven walks up the parent-child level, Until a project with the dependencymanagement element is found, then it will use the version number specified in the Dependencymanagement element, and of course if the subproject defines a version, it will overwrite the top-level POM The version in the Dependencymanagement element

Here is an example

Parent POM Configuration file

<dependencyManagement><!--Configuration Item Dependency--><dependencies><dependency><groupid> org.apache.zookeeper</groupid><artifactid>zookeeper</artifactid><version>${ Zookeeper.version}</version></dependency><dependency><groupid>org.opensymphony.quartz </groupid><artifactid>quartz-all</artifactid><version>${quartz.version}</version ></dependency><dependency><groupid>oro</groupid><artifactid>oro</ Artifactid><version>${oro.version}</version></dependency></dependencymanagement>

We just need to write this in the submodule.

<!--configuration Item Dependency--><dependencies><dependency><groupid>org.apache.zookeeper</groupid> <artifactId>zookeeper</artifactId></dependency></dependencies>

And so next time we need to upgrade our version, we just have to change it in the parent module, so it's not forever.

The power of MAVEN is much more than that, next analysis ~ ~

Maven Interpretation: How Project-dependent management optimizes