harmonyOS引入依赖

讲讲 Maven 依赖

• 1.依赖配置
• 2.依赖范围
• 3.依赖冲突
• 4.排除依赖

1.依赖配置

配置信息示例：

<project>
    <dependencies>
        <dependency>
            <groupId></groupId>
            <artifactId></artifactId>
            <version></version>
            <type>...</type>
            <scope>...</scope>
            <optional>...</optional>
            <exclusions>
                <exclusion>
                  <groupId>...</groupId>
                  <artifactId>...</artifactId>
                </exclusion>
          </exclusions>
        </dependency>
      </dependencies>
</project>

配置说明 ：

• dependencies： 一个 pom.xml 文件中只能存在一个这样的标签，是用来管理依赖的总标签。
• dependency：包含在 dependencies 标签中，可以有多个，每一个表示项目的一个依赖。
• groupId,artifactId,version(必要)：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，Maven 根据坐标才能找到需要的依赖。
• type(可选)：依赖的类型，对应于项目坐标定义的 packaging。大部分情况下，该元素不必声明，其默认值是 jar。
• scope(可选)：依赖的范围，默认值是 compile。
• optional(可选)： 标记依赖是否可选
• exclusions(可选)：用来排除传递性依赖,例如 jar 包冲突

---

2.依赖范围

classpath 用于指定 .class 文件存放的位置，类加载器会从该路径中加载所需的 .class 文件到内存中。

Maven 在编译、执行测试、实际运行有着三套不同的 classpath：

• 编译 classpath ：编译主代码有效
• 测试 classpath ：编译、运行测试代码有效
• 运行 classpath ：项目运行时有效

Maven 的依赖范围如下：

• compile：编译依赖范围（默认），使用此依赖范围对于编译、测试、运行三种都有效，即在编译、测试和运行的时候都要使用该依赖 Jar 包。
• test：测试依赖范围，从字面意思就可以知道此依赖范围只能用于测试，而在编译和运行项目时无法使用此类依赖，典型的是 JUnit，它只用于编译测试代码和运行测试代码的时候才需要。
• provided ：此依赖范围，对于编译和测试有效，而对运行时无效。比如 servlet-api.jar 在 Tomcat 中已经提供了，我们只需要的是编译期提供而已。
• runtime：运行时依赖范围，对于测试和运行有效，但是在编译主代码时无效，典型的就是 JDBC 驱动实现。
• system：系统依赖范围，使用 system 范围的依赖时必须通过 systemPath 元素显示地指定依赖文件的路径，不依赖 Maven 仓库解析，所以可能会造成建构的不可移植。

---

3.依赖冲突

1、对于 Maven 而言，同一个 groupId 同一个 artifactId 下，只能使用一个 version。

<dependency>
    <groupId>in.hocg.boot</groupId>
    <artifactId>mybatis-plus-spring-boot-starter</artifactId>
    <version>1.0.48</version>
</dependency>
<!-- 只会使用 1.0.49 这个版本的依赖 -->
<dependency>
    <groupId>in.hocg.boot</groupId>
    <artifactId>mybatis-plus-spring-boot-starter</artifactId>
    <version>1.0.49</version>
</dependency>

若相同类型但版本不同的依赖存在于同一个 pom 文件，只会引入后一个声明的依赖

2、项目的两个依赖同时引入了某个依赖。

举个例子，项目存在下面这样的依赖关系：

依赖链路一：A -> B -> C -> X(1.0)
依赖链路二：A -> D -> X(2.0)

这两条依赖路径上有两个版本的 X，为了避免依赖重复，Maven 只会选择其中的一个进行解析。

哪个版本的 X 会被 Maven 解析使用呢?

Maven 在遇到这种问题的时候，会遵循 路径最短优先 和 声明顺序优先 两大原则。解决这个问题的过程也被称为 Maven 依赖调解 。

路径最短优先🦈

依赖链路一：A -> B -> C -> X(1.0) // dist = 3
依赖链路二：A -> D -> X(2.0) // dist = 2

依赖链路二的路径最短，因此，X(2.0)会被解析使用。

不过，你也可以发现。路径最短优先原则并不是通用的，像下面这种路径长度相等的情况就不能单单通过其解决了：

依赖链路一：A -> B -> X(1.0) // dist = 3
依赖链路二：A -> D -> X(2.0) // dist = 2

因此，Maven 又定义了声明顺序优先原则。

声明顺序优先🐬

在依赖路径长度相等的前提下，在 pom.xml 中依赖声明的顺序决定了谁会被解析使用，顺序最前的那个依赖优胜。该例中，如果 B 的依赖声明在 D 之前，那么 X (1.0)就会被解析使用。

<!-- A pom.xml -->
<dependencies>
    ...
    dependency B
    ...
    dependency D
</dependencies>

---

4.排除依赖

单纯依赖 Maven 来进行依赖调解，在很多情况下是不适用的，需要我们手动排除依赖。

举个例子，当前项目存在下面这样的依赖关系：

依赖链路一：A -> B -> C -> X(1.5) // dist = 3
依赖链路二：A -> D -> X(1.0) // dist = 2

根据路径最短优先原则，X(1.0) 会被解析使用，也就是说实际用的是 1.0 版本的 X。

但是！！！这会一些问题：如果 D 依赖用到了 1.5 版本的 X 中才有的一个类，运行项目就会报NoClassDefFoundError错误。如果 D 依赖用到了 1.5 版本的 X 中才有的一个方法，运行项目就会报NoSuchMethodError错误。

如何解决呢？ 我们可以通过exclusive标签手动将 X(1.0) 给排除。

<dependency>
    ......
    <exclusions>
      <exclusion>
        <artifactId>x</artifactId>
        <groupId>org.apache.x</groupId>
      </exclusion>
    </exclusions>
</dependency>