Maven依赖

Posted 2020-12-13 Nemo&

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Maven依赖相关的知识，希望对你有一定的参考价值。

POM 依赖

Maven 解析依赖信息时，会到本地仓库中查找被依赖的 jar 包。

groupid：公司火组织域名倒序 + 项目名
artifactid：模块名
version：版本
scope：依赖的范围主要分为以下三种
- complie：
  - 对主程序是否有效：√
  - 对测试程序是否有效：√
  - 是否参与打包：√
- test：
  - 对主程序是否有效：×
  - 对测试程序是否有效：√
  - 是否参与打包：×
  - 典型例子：junit
- provided：
  - 对主程序是否有效：√
  - 对测试程序是否有效：√
  - 是否参与打包：×
  - 是否参与部署：×
  - 典型例子：servlet-api.jar
exclusions：排除某个已有依赖。

依赖管理

Maven 一个核心的特性就是依赖管理。当我们处理多模块的项目（包含成百上千个模块或者子项目），模块间的依赖关系就变得非常复杂，管理也变得很困难。针对此种情形，Maven 提供了一种高度控制的方法。

可传递性依赖发现
一种相当常见的情况，比如说 A 依赖于其他库 B。如果，另外一个项目 C 想要使用 A ，那么 C 项目也需要使用库 B。

Maven 可以避免去搜索所有所需库的需求。Maven 通过读取项目文件（pom.xml），找出它们项目之间的依赖关系。

我们需要做的只是在每个项目的 pom 中定义好直接的依赖关系。其他的事情 Maven 会帮我们搞定。

通过可传递性的依赖，所有被包含的库的图形会快速的增长。当有重复库时，可能出现的情形将会持续上升。Maven 提供一些功能来控制可传递的依赖的程度。

功能	功能描述	备注
依赖调节	决定当多个手动创建的版本同时出现时，哪个依赖版本将会被使用。	如果两个依赖版本在依赖树里的深度是一样的时候，第一个被声明的依赖将会被使用。
依赖管理	直接的指定手动创建的某个版本被使用。	例如当一个工程 C 在自己的依赖管理模块包含工程 B，即 B 依赖于 A，那么 A 即可指定在 B 被引用时所使用的版本。
依赖范围	包含在构建过程每个阶段的依赖。
依赖排除	任何可传递的依赖都可以通过 "exclusion" 元素被排除在外。	举例说明，A 依赖 B， B 依赖 C，因此 A 可以标记 C 为 "被排除的"。
依赖可选	任何可传递的依赖可以被标记为可选的，通过使用 "optional" 元素。	例如：A 依赖 B， B 依赖 C。因此，B 可以标记 C 为可选的，这样 A 就可以不再使用 C。

依赖范围(scope)

传递依赖发现可以通过使用如下的依赖范围来得到限制：

范围	描述	备注
编译阶段(complie)	该范围表明相关依赖是只在项目的类路径下有效。默认取值。	编译时需要用到的依赖
供应阶段(provided)	该范围表明相关依赖是由运行时的 JDK 或者网络服务器提供的。	JRE 运行环境需要提供的依赖
运行阶段	该范围表明相关依赖在编译阶段不是必须的，但是在执行阶段是必须的。
测试阶段(test)	该范围表明相关依赖只在测试编译阶段和执行阶段。	测试时需要用到的依赖
系统阶段	该范围表明你需要提供一个系统路径。
导入阶段	该范围只在依赖是一个 POM 里定义的依赖时使用。同时，当前项目的 POM 文件的部分定义的依赖关系可以取代某特定的 POM。

    <!--该元素描述了项目相关的所有依赖。 这些依赖组成了项目构建过程中的一个个环节。它们自动从项目定义的仓库中下载。要获取更多信息，请看项目依赖机制。 -->
    <dependencies>
        <dependency>
            <!--依赖的group ID -->
            <groupId>org.apache.maven</groupId>
            <!--依赖的artifact ID -->
            <artifactId>maven-artifact</artifactId>
            <!--依赖的版本号。 在Maven 2里, 也可以配置成版本号的范围。 -->
            <version>3.8.1</version>
            <!-- 依赖类型，默认类型是jar。它通常表示依赖的文件的扩展名，但也有例外。一个类型可以被映射成另外一个扩展名或分类器。类型经常和使用的打包方式对应， 
                尽管这也有例外。一些类型的例子：jar，war，ejb-client和test-jar。如果设置extensions为 true，就可以在 plugin里定义新的类型。所以前面的类型的例子不完整。 -->
            <type>jar</type>
            <!-- 依赖的分类器。分类器可以区分属于同一个POM，但不同构建方式的构件。分类器名被附加到文件名的版本号后面。例如，如果你想要构建两个单独的构件成 
                JAR，一个使用Java 1.4编译器，另一个使用Java 6编译器，你就可以使用分类器来生成两个单独的JAR构件。 -->
            <classifier></classifier>
            <!--依赖范围。在项目发布过程中，帮助决定哪些构件被包括进来。欲知详情请参考依赖机制。 - compile ：默认范围，用于编译 - provided：类似于编译，但支持你期待jdk或者容器提供，类似于classpath 
                - runtime: 在执行时需要使用 - test: 用于test任务时使用 - system: 需要外在提供相应的元素。通过systemPath来取得 
                - systemPath: 仅用于范围为system。提供相应的路径 - optional: 当项目自身被依赖时，标注依赖是否传递。用于连续依赖时使用 -->
            <scope>test</scope>
            <!--仅供system范围使用。注意，不鼓励使用这个元素，并且在新的版本中该元素可能被覆盖掉。该元素为依赖规定了文件系统上的路径。需要绝对路径而不是相对路径。推荐使用属性匹配绝对路径，例如${java.home}。 -->
            <systemPath></systemPath>
            <!--当计算传递依赖时， 从依赖构件列表里，列出被排除的依赖构件集。即告诉maven你只依赖指定的项目，不依赖项目的依赖。此元素主要用于解决版本冲突问题 -->
            <exclusions>
                <exclusion>
                    <artifactId>spring-core</artifactId>
                    <groupId>org.springframework</groupId>
                </exclusion>
            </exclusions>
            <!--可选依赖，如果你在项目B中把C依赖声明为可选，你就需要在依赖于B的项目（例如项目A）中显式的引用对C的依赖。可选依赖阻断依赖的传递性。 -->
            <optional>true</optional>
        </dependency>
    </dependencies>

依赖的原则

作用：解决模块工程之间的 jar 包冲突问题。
原则：
- 路径最短者优先
- 路径相同时，先声明者优先
  
  先声明指的是 dependency 标签的声明顺序。

聚合

在中的聚合工程中使用 modules/module 标签组合，指定模块工程的相对路径即可。
（自己编写的工程，聚合在一起，相当于 import）

<modules>
    <module>../Hello</module>
    <module>../HelloFriend</module>
    <module>../MakeFriends</module>
</modules>

Maven 库站

我们可以到 http://mvnrepository.com/ 搜索需要的 jar 包的依赖信息。