maven坐标引用依赖 maven依赖的基本坐标

转载

mob64ca13fba42b 2024-04-19 14:29:51

文章标签 maven坐标引用依赖 maven jar json ide 文章分类 架构后端开发

1.坐标

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

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

2.依赖

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

2.1 依赖解析过程

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

maven坐标引用依赖 maven依赖的基本坐标_jar

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）:

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

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

基于更新策略更新（updatePolicy= always），则总是尝试去远程仓库拉取最新版本
强制快照更新------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，因此各个项目间的依赖也会进行传递

maven坐标引用依赖 maven依赖的基本坐标_maven坐标引用依赖_02

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

maven 默认的依赖仲裁规则是：

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

依赖冲突

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

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

依赖冲突根因： Maven项目的依赖关系通过pom文件进行管理，项目的pom文件中声明了项目的依赖，而该项目的每一个依赖也有着自己对应的pom文件。因此，Maven项目的依赖关系实际上是一颗巨大的树状结构，我们向项目中添加依赖，实际上是将一颗树合并至另一颗树——不过这并不是简单的将两颗依赖树嫁接在一起就结束了。
由于Maven通过groupId，artifactId，version三个维度来唯一标识某一个依赖包，而且在同一个Maven项目只能依赖某个依赖包的特定版本。因此，在合并两颗依赖树的过程中，如果在树上出现了GroupId，ArtifactId相同而Version不同的依赖包时，这时便出现了依赖冲突。

排包方式：

1.当发生jar冲突程序报错时，可以使用mvn命令查出项目最终依赖的jar包树，看版本是否是我们预期的：

maven坐标引用依赖 maven依赖的基本坐标_ide_03