𝓝𝓮𝓶𝓸&博客

𝓝𝓮𝓶𝓸&博客

【Maven】依赖、继承、聚合

POM 依赖

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

  • groupid：公司或组织域名倒序 + 项目名
  • artifactid：模块名
  • version：版本
  • scope：依赖的范围主要分为以下三种
    • complie：编译阶段（默认）
      • 对主程序是否有效：√
      • 对测试程序是否有效：√
      • 是否参与打包：√
    • test：测试阶段
      • 对主程序是否有效：×
      • 对测试程序是否有效：√
      • 是否参与打包：×

      测试通过了才打包，所以不需要打包测试程序。

      • 典型例子：junit
    • provided：提供运行阶段（仅仅用来提供给运行）（代表目标环境已提供）
      • 对主程序是否有效：√
      • 对测试程序是否有效：√
      • 是否参与打包：×
      • 是否参与部署：×
      • 典型例子：servlet-api.jar

        如 servlet-api一般tomcat里面都会自带，所以把scope调成provided，目标环境已提供，打包的时候就不用带上servlet-api了。

  • exclusions：排除某个已有依赖。

依赖管理

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

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

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

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

类比：比如高等数学的建立依赖于初等数学，而我们解题需要用到高等数学的知识，那么我们只需要导入高等数学即可，其他的初等数学的知识 Maven 会帮我们导入。
解题需要依赖高等数学，高等数学需要依赖初等数学，这就是一个传递依赖，我们只需要将项目的直接依赖写入，其他的所需的传递依赖，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 运行环境需要提供的依赖
代表在编译和测试的时候用，运行，打包的时候不会打包进去
运行阶段(runtime) 该范围表明相关依赖在编译阶段不是必须的，但是在执行阶段是必须的。 表示当前依赖包只参与运行周期，其他跳过了
测试阶段(test) 该范围表明相关依赖只在测试编译阶段和执行阶段。 测试时需要用到的依赖
表示当前依赖包只参与测试时的工作：比如Junit
系统阶段(system) 该范围表明你需要提供一个系统路径。 从参与度和provided一致，不过被依赖项不会从maven远程仓库下载，而是从本地的系统拿。需要systemPath属性来定义路径
导入阶段 该范围只在依赖是一个 POM 里定义的依赖时使用。同时，当前项目的 POM 文件的 部分定义的依赖关系可以取代某特定的 POM。

runtime阶段实例：（JDBC 驱动程序）如MySQL驱动应该只在运行时被加载，而不会在编译时和测试时被加载。

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.28</version>
    <scope>runtime</scope>
</dependency>

    <!--该元素描述了项目相关的所有依赖。 这些依赖组成了项目构建过程中的一个个环节。它们自动从项目定义的仓库中下载。要获取更多信息，请看项目依赖机制。 -->
    <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>

依赖的原则

（自己编写的工程，依赖相当于 import）

  • 作用：解决模块工程之间的 jar 包冲突问题。
  • 原则：
    • 路径最短者优先
    • 路径相同时，先声明者优先

    先声明指的是 dependency 标签的声明顺序。

继承

  • 现状：需要统一管理依赖
    Hello 依赖的 junit：4.0
    HelloFriend 依赖的 junit：4.0
    MakeFriends 依赖的 junit：4.9
    由于 test 范围的依赖不能传递，所以必然会分散在各个模块工程中，很容易造成版本不一致。
  • 需求：统一管理各个模块工程中对 junit 依赖的版本
  • 解决思路：将 junit 依赖统一提取到“父”工程中，在子工程中声明 junit 依赖时不指定版本，以父工程中统一设定的为准。同时也便于修改。
  • 操作步骤：
    1. 创建一个 Maven 工程作为父工程。

    注意：打包的方式 pom，只是一个整合的 maven 文件，不需要写程序

    1. 在子工程中声明对父工程的引用
    2. 将子工程的坐标中与父工程坐标中重复的内容删除
    3. 在父工程中统一 junit 的依赖
    4. 在子工程中删除 junit 依赖的版本号部分

依赖管理(dependencyManagement)

在父工程中管理依赖dependencyManagement
将 Parent 项目中的 dependencies 标签，用 dependencyManagement 标签括起来。

Maven使用dependencyManagement元素来提供了一种管理依赖版本号的方式。
通常会在一个组织或者项目的最顶层的父POM中看到dependencyManagement元素。
使用pom.xml中的dependencyManagement元素能让所有在子项目中引用一个依赖而不用显式的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement 元素的项目,然后它就会使用这个dependencyManagement元索中指定的版本号。

这样做的好处就是:如果有多个子项目都引用同一样依赖，则可以避免在每个使用的子项目里都声明一个版本号,这样当想升级或切换到另一个版本时，只需要在顶层父容器里更新，而不需要一个一个子项目的修改;另外如果某个子项目需要另外的一个版本，只需要声明version就可。

  • dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显式地声明需要用的依赖。
  • 如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom；
  • 如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。
<dependencyManagement> 
  <dependencies> 
    <dependency> 
      <groupId>junit</groupId> 
      <artifactId>junit</artifactId> 
      <version>4.9</version> 
      <scope>test</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

在子项目中重新指定需要的依赖，删除范围和版本号

<dependencies>
  <dependency>
    <groupId>junit</groupId> 
    <artifactId>junit</artifactId>
  </dependency>
</dependencies>

直接继承(dependencies)

父项目中直接使用dependencies，而不用dependencyManagement，子项目中会直接继承此依赖，而不需要额外进行声明。

  <dependencies> 
    <dependency> 
      <groupId>junit</groupId> 
      <artifactId>junit</artifactId> 
      <version>4.9</version> 
      <scope>test</scope>
    </dependency>
  </dependencies>

聚合

聚合可以在父工程中写。
在 Maven 中的聚合工程中使用 modules/module 标签组合，指定模块工程的相对路径即可。

  • 作用：一键安装各个模块工程
  • 配置方式：在一个“总的聚合工程”中配置各个参与聚合的模块。
  • 使用方式：在聚合工程的 pom.xml 上点右键→run as→maven install
<modules>
    <!-- 交换顺序不影响聚合 -->
	<module>../Hello</module>
	<module>../HelloFriend</module>
	<module>../MakeFriends</module>
</modules>

作用

  1. 项目中定义的依赖信息都可以在父工程进行定义，子模块不需要定义依赖信息，直接继承过来即可
  2. 将各个子模块聚合在一起
  3. 将父工程保存到maven本地仓库（注意：别忘了这一步）

Maven 库站

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

推荐配置方式

  1. 使用 properties 标签内使用自定义标签统一声明版本号，以便于版本的更新。

类比：宏定义常量。
xml <properties> <spring.version>4.0.0.RELEASE</spring.version> </properties>

  1. 在需要统一版本的威兹，使用${自定义标签名}引用声明的版本号
    <version>${spring.version}</version>

其实 properties 标签配合自定义标签声明数据的配置并不是只能用于声明依赖的版本号。

posted @ 2020-06-27 15:02  Nemo&  阅读(422)  评论(0)  编辑  收藏  举报