Maven（四）Maven的依赖

秒速五厘米 2021-06-22 15:37 563阅读 0赞

### 目录 ###

*  第三个工程
 *  Maven的依赖\[高级\]
 *   *  1. 依赖的传递性
     *  2. 依赖的排除
     *  3. 依赖的原则
     *   *  ① 路径最短者优先
         *  ② 路径相同时先声明者优先
     *  4. 统一管理依赖的版本

# 第三个工程 #

我们接下来建立第三个maven工程。

**工程坐标：**

groupId：com.veeja.maven
    ArtifactId：MakeFriends
    Package：com.veeja.maven

**在src/main/java中新建类com.veeja.maven.MakeFriends：**

package com.veeja.maven;
    
    public class MakeFriends { 
    	public String makeFriends(String name) { 
    		HelloFriend friend = new HelloFriend();
    		friend.sayHelloToFriend("litingwei");
    		String str = "Hey," + friend.getMyName() + " make a friend please.";
    		System.out.println(str);
    		return str;
    	}
    }

**在src/test/java中新建类com.veeja.maven.MakeFriendsTest：**

package com.veeja.maven;
    
    import static junit.framework.Assert.assertEquals;
    import org.junit.Test;
    
    public class MakeFriendsTest { 
    	@Test
    	public void testMakeFriends() { 
    		MakeFriends makeFriend = new MakeFriends();
    		String str = makeFriend.makeFriends("litingwei");
    		assertEquals("Hey,John make a friend please.", str);
    	}
    }

接下来，我们要引入依赖信息。

<dependencies>
    	<dependency>
    		<groupId>junit</groupId>
    		<artifactId>junit</artifactId>
    		<version>4.9</version>
    		<scope>test</scope>
    	</dependency>
    	<dependency>
    		<groupId>com.veeja.maven</groupId>
    		<artifactId>HelloFriend</artifactId>
    		<version>0.0.1-SNAPSHOT</version>
    		<type>jar</type>
    		<scope>compile</scope>
    	</dependency>
    </dependencies>

添加完依赖信息，就会生成我们的Maven依赖：  
![在这里插入图片描述][20200329095651860.png]

这个时候我们程序就不会报错了，但是我们编译一下，右键项目-Run As-Maven build-compile，我们发现：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70]  
构建失败，找不到HelloFriend.jar。这是因为我们以前的HelloFriend并没有安装到我们的Maven仓库中，我们把HelloFriend安装一下，`maven install`。然后再次compile一下，就成功了：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 1]

# Maven的依赖\[高级\] #

接下来我们借助上面的工程，我们分析一下其他的依赖问题。

## 1. 依赖的传递性 ##

我们回顾一下创建的三个工程，HelloMaven——HelloFriend——MakeFriends，它们是一层层依赖的。  
这个时候，我们想在HelloMaven中添加一个spring-core依赖。

**我们在pom文件中添加：**

<dependency>
    	<groupId>org.springframework</groupId>
    	<artifactId>spring-core</artifactId>
    	<version>4.0.0.RELEASE</version>
    	<scope>compile</scope>
    </dependency>

**我们注意这么几点，首先是这个依赖范围是`compile`，**  
其次在Maven dependencies中出现了相应的jar包，  
![在这里插入图片描述][20200329101355892.png]  
然后我们去HelloFriend工程下面找一找，发现：  
![在这里插入图片描述][20200329101517478.png]  
这个工程也自动引入了这个文件。  
我们可以在HelloFriend的pom文件中的依赖层次结构中，直观形象的看到这一点：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 2]

**我们在把HelloMaven中spring-core的依赖范围修改为test，**  
![在这里插入图片描述][20200329101641682.png]  
我们再去看一看HelloFriend中，  
![在这里插入图片描述][20200329101715136.png]  
spring-core.jar消失了。

**最后我们修改为provided，**  
![在这里插入图片描述][20200329101809239.png]  
我们再去看一看HelloFriend中，  
![在这里插入图片描述][20200329101822933.png]  
也是没有的。

这个时候我们可以得出一些简单的结论，  
**1. 非compile范围的依赖不能传递，必须在有需要的工程中单独加入。**  
2. 依赖的传递性使得可以传递的依赖不必在每个模块工程中都重复声明，在“最底层”的工程中依赖一次即可。

## 2. 依赖的排除 ##

我们再看上面的例子，  
在HelloMaven引入了spring-core.jar，依赖的范围是compile，因为依赖的传递性，在HelloFriend中也会出现相应的jar包。  
![在这里插入图片描述][20200329104031810.png]  
但是我们可以注意到，不仅有了spring-core的jar包，还有一个commons-logging的jar包，其实这也很简单，因为spring-core是依赖commons-logging的。  
但是，如果我们不想HelloFriend把commons-logging给带进来，只需要spring-core怎么办？  
**这个时候我们就要用到依赖的排除。**

**依赖排除的设置**  
我们需要在依赖中设置一个标签：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 3]  
其中的groupID和artifactID填写对应jar包的信息就可以了。如果我们不知道commons-logging的对应信息，可以在Dependency Hierarchy选项卡中对着相应的jar右键，点击Open POM：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 4]  
在这里面就可以找到相对应的信息了：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 5]  
添加上依赖排除信息，然后保存pom文件。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 6]  
这个时候我们就发现，HelloFriend中就会去掉相应的jar包了。  
![在这里插入图片描述][20200329105855868.png]

## 3. 依赖的原则 ##

依赖的原则是为了解决模块工程之间的jar包冲突问题。

### ① 路径最短者优先 ###

我们举一个例子。  
比如存在以下依赖关系：  
![在这里插入图片描述][20200329111010533.png]  
1依赖2；  
2依赖3，2依赖xxx-1.0.1；  
3依赖xxx-1.0.2。

根据依赖的传递性，1会同时依赖xxx-1.0.1和xxx-1.0.2。那么这个时候，1会依赖哪一个呢？  
答案是1会依赖xxx-1.0.1，因为1到xxx-1.0.1的路径长度为2，1到xxx-1.0.2的路径长度为3。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 7]  
这就是路径最短者优先原则。

### ② 路径相同时先声明者优先 ###

如果有以下场景，  
1依赖2；2依赖xxx-1.0.1；  
1依赖3；3依赖xxx-1.0.2。  
![在这里插入图片描述][20200329111839766.png]  
这个时候，依赖会怎么传递呢？  
那么就会根据先声明者优先原则。  
在1的pom文件中，先声明的依赖会被采纳，也就是如果你在1中先声明了2依赖，就会使用1.0.1，如果先声明了3，就会采用1.0.2。

## 4. 统一管理依赖的版本 ##

比如有一种这样的情况：  
![在这里插入图片描述][20200329112729893.png]  
**这里对Spring各个jar包的依赖版本都是4.0.0，如果需要统一升级为4.1.1，怎么办?手动逐一修改不太可靠，既繁琐又容易出错。**

**建议的配置方式：**  
使用properties标签内使用自定义标签统一声明版本号，例如：

在需要统一版本的位置，使用`${自定义标签名}`引用声明，即：

<dependency>
    	<groupId>org.springframework</groupId>
    	<artifactId>spring-core</artifactId>
    	<version>${veeja.spring.version}</version>
    	<scope>compile</scope>
    </dependency>

**这样就完成了对版本的统一控制。**

其实properties标签配合自定义标签声明数据的配置并不是只能用于声明依赖的版本号。凡是需要统一声明后再引用的场合都可以使用。

--------------------

END.

[20200329095651860.png]: /images/20210615/fff50fa2f0774e9b90adf0f87eabc1d2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70]: /images/20210615/85953c6be24e4130ad652c3483431a3e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 1]: /images/20210615/227cf5bdd6a3456caaf382ebb2950494.png
[20200329101355892.png]: /images/20210615/0916905768b24b0985cbc18f07f96ac3.png
[20200329101517478.png]: /images/20210615/c4f410546f89418fa97ca651925b4e4a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 2]: /images/20210615/c8955be4bca04b0cbf9f7272eae13475.png
[20200329101641682.png]: /images/20210615/d0170e69f94b45b7a020012cfba984f7.png
[20200329101715136.png]: /images/20210615/984f5aad23bd432e95425904376cf2d9.png
[20200329101809239.png]: /images/20210615/539da6d1572a47c59ccc161b305ecb9a.png
[20200329101822933.png]: /images/20210615/05d402da38224ec1864a4918aa323247.png
[20200329104031810.png]: /images/20210615/d122bebe0a984b688d471ef2eb157eb0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 3]: /images/20210615/4185d6f0887a45d1b2e7bdab20e336a4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 4]: /images/20210615/b34debd13d3d4e6f98ae51f89d3022d7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 5]: /images/20210615/f9687ec1a40a48dfafe2d0e501454211.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 6]: /images/20210615/fa1a837d70e44ab4b0eca0b24813c591.png
[20200329105855868.png]: /images/20210615/3f346de7ec984f12b2f64a22cdbdf52f.png
[20200329111010533.png]: /images/20210615/3bb8f0b27956495badab2e8f4fef8751.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTQ1NjUxMjc_size_16_color_FFFFFF_t_70 7]: /images/20210615/e70b0e671b334f6bb1a20fc875e7ee0a.png
[20200329111839766.png]: /images/20210615/657cd1d3864d48b0b8b06590d0fd3950.png
[20200329112729893.png]: /images/20210615/7b0da7349be7460fb3a6d4cefa9b444e.png