【Maven】基本使用：坐标与依赖

た入场券 2022-10-21 11:59 155阅读 0赞

## 1.坐标 ##

在数学中, 任何一个坐标可以唯一确定一个“点”。Maven 中坐标是Jar包的唯一标识，坐标元素包括groupId、artifactId、version、packaging:

<table> 
 <thead> 
  <tr> 
   <th align="left">元素</th> 
   <th align="left">描述</th> 
   <th align="left">说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">groupId</td> 
   <td align="left">定义当前模块隶属的实际Maven项目</td> 
   <td align="left">中小企业常常直接对应公司/组织</td> 
  </tr> 
  <tr> 
   <td align="left">artifactId</td> 
   <td align="left">定义实际项目中的一个Maven模块</td> 
   <td align="left">唯一标识一个模块</td> 
  </tr> 
  <tr> 
   <td align="left">version</td> 
   <td align="left">定义当前项目所处版本</td> 
   <td align="left">SNAPSHOT 表示不稳定的版本。 <br> LATEST 指最新发布的版本，可能是个发布版，也可能是一个snapshot版。 <br>RELEASE 指最后一个发布版。</td> 
  </tr> 
  <tr> 
   <td align="left">packaging</td> 
   <td align="left">定义Maven项目打包方式</td> 
   <td align="left">有jar(默认)、war、pom、maven-plugin等.</td> 
  </tr> 
  <tr> 
   <td align="left">classifier</td> 
   <td align="left">附属构件(如javadoc、sources)</td> 
   <td align="left">须有附加插件的帮助</td> 
  </tr> 
  <tr> 
   <td align="left">scope</td> 
   <td align="left">依赖范围</td> 
   <td align="left">具体见下面依赖部分</td> 
  </tr> 
 </tbody> 
</table>

## 2.依赖 ##

依赖即：A -->B，B–>C，C–>D这种项目间的依存关系。在java的jvm内，依赖的最终表现是，项目A启动时，其依赖的jar包必须都对应放入其classpath路径内。

### 2.1 依赖解析过程 ###

当我们执行 Maven 构建命令时，Maven 开始按照以下顺序查找依赖的库：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]

> Maven版本：
> 
>  *  version（SNAPSHOT）：快照版本。随时更新不稳定的，每个版本都只是特定时间点的快照。同时，SNAPSHOT的不稳定性会带来风险 ，本地仓库中快照版本的依赖的目录下会看到带有时间戳的jar包。  
>     例如：A–>B-1.3.8-SNAPSHOT（理解为A依赖了B的1.3.8-SNAPSHOT版本），那么B-1.3.8-SNAPSHOT更新且重新deploy到仓库之后，A只 需要重新构建就可以拿到最新的代码，不用修改依赖B的版本。这样达到了变更传达的透明性。
>  *  version（RELEASE)：发布（正式）版本，是稳定的版本号，应该一旦发布永远不变。
>  *  version（LATEST）：不稳定版本，不管是快照还是发布版，就是去拉最新的。
> 
>   
> 注意，不推荐直接使用`<version>RELEASE<version>` 和 `<version>LATEST<version>`，因为它们都会在打包时去远程仓库拉取最新的，从而可能导致同一项目在打包时依赖不同的jar包。

依赖是具体的发布版本（xxx.RELEASE）:

1.  在本地仓库中搜索，找到则成功。
2.  在远程仓库中搜索，找到则下载。
3.  如果没有设置远程仓库，Maven 默认去中央仓库搜索，找到则下载。
4.  在一个或多个远程仓库中搜索依赖的文件，如果找到则下载到本地仓库以备将来引用，否则 Maven 将停止处理并抛出错误（无法找到依赖的文件）。

依赖是快照版本（xxx.SNAPSHOT、RELEASE、LATEST）：

1.  基于更新策略更新（updatePolicy= always），则总是尝试去远程仓库拉取最新版本
2.  强制快照更新------mvn clean install-U

### 2.2 依赖范围 ###

Maven 中的scope有compile、test、runtime、provided、system，其中默认的值是compile。

1）Compile

compile ：默认范围，编译范围，**编译和打包都会依赖**

默认就是compile，什么都不配置也就是意味着compile。compile表示被依赖项目需要参与当前项目的编译，当然后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去。

2）runtime

runtime: 运行时范围，**打包时依赖，编译不会**。如：mysql-connector-java.jar。

runtime表示被依赖项目无需参与项目的编译，不过后期的测试和运行周期需要其参与。与compile相比，跳过编译而已，说实话在终端的项目（非开源，企业内部系统）中，和compile区别不是很大。举例说明一下：在代码中调用了一个接口一个方法，这个接口并没有对应的实现。这段代码在编译期间并不会报错，但是在代码运行的时候会出现问题。jdbc驱动可以使用runtime的scope，因为只有在真正运行的时候才会调用到驱动的代码。

3）Test

test: 测试范围，编译运行测试用例依赖，**不会打包进去**。如：junit.jar。

scope为test表示依赖项目仅仅参与测试相关的工作，包括测试代码的编译，执行。比较典型的如junit。

junit只有在执行单元测试时候需要，当我们进行真正项目发布的时候junit是不需要进行编译和发布的。

4）provided

provided：提供范围，**编译时依赖，但不会打包进去**。如：servlet-api.jar 。

provided意味着打包的时候可以不用包进去，别的设施(Web Container)会提供。事实上该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是在打包阶段做了exclude的动作。  
比如：

<dependency>  
             <groupId>javax.servlet</groupId>  
              <artifactId>servlet-api</artifactId>  
                <version>2.5</version>  
                <scope>provided</scope>  
            </dependency>  
            <dependency>  
                <groupId>javax.servlet.jsp</groupId>  
                <artifactId>jsp-api</artifactId>  
                <version>2.1</version>  
                <scope>provided</scope>  
            </dependency>

tomcat会提供这个servlet-api.jar 包，所以当我们项目发布的时候这个包是不需要打到包里的

5）system

system: 需要外在提供相应的元素。通过systemPath来取得 ----- 一般禁止使用。

从参与度来说，也provided相同，不过被依赖项不会从maven仓库抓，而是从本地文件系统拿，一定需要配合systemPath属性使用。

> 注：profile，一般在mvc项目中根据配置运行环境与测试环境代码等

### 2.3 依赖传递 ###

即一个项目A依赖项目B，项目B又依赖项目C，因此各个项目间的依赖也会进行传递

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]

上述过程中，项目Mall归结起来，依赖的fastjson会有三个版本。而我们的jvm最终肯定只能接受一个版本的jar，所以必须有所取舍。

maven 默认的取舍规则是：

*  路径最短原则：product和customer里的fastjson引用路径较短，路径为两步 ;pay项目里的fastjson引用路径较长，路径为三步。因此pay中的fastjson被淘汰
 *  同路径长度下，谁先声明谁优先： product和customer中的fastjson路径相同，那么就看在pom中是先声明product还是先声明customer，谁先用谁的

### 2.4 依赖冲突 ###

在依赖传递里，我们看到，maven根据自己的规则为我们取舍出了一个版本的jar，但此jar版本选择可能会与我们的项目预期不符。

比如，我们最终想的版本是fastjson:1.2.30版本-----但它在第一步即被淘汰掉了，所以我们项目运行可能会出错（项目中使用到了1.2.30版本的特性）。此问题即是我们常遇到的jar包冲突问题

补救方式：

1.  当发生jar冲突程序报错时，可以使用mvn命令查出项目最终依赖的jar包树，看版本是否是我们预期的：  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]
2.  使用exclusions将product和customer中的fastjson包排除掉，用法如下图：  
    ![在这里插入图片描述][20201109012253974.png_pic_center]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221021/f78dfdb290f045fcad040e3b44f4bc55.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221021/1190f51a97984905b52b1a43c9aa3201.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221021/e9b6dfe5092e488eb8a77e02ac282e61.png
[20201109012253974.png_pic_center]: /images/20221021/b41a335bbc2d47e29067551ff299277c.png