AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

Maven简介（六）——Dependency

2014-04-30 963
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
简介： 7      Dependency介绍 7.1     依赖的传递性 当项目A依赖于B，而B又依赖于C的时候，自然的A会依赖于C，这样Maven在建立项目A的时候，会自动加载对C的依赖。

7      Dependency介绍

7.1     依赖的传递性

当项目A依赖于B，而B又依赖于C的时候，自然的A会依赖于C，这样Maven在建立项目A的时候，会自动加载对C的依赖。

依赖传递对版本的选择

假设A依赖于B和C，然后B依赖于D，D又依赖于E1.0，C直接依赖于E2.0，那么这个时候A依赖的是E1.0还是E2.0，还是这两个都依赖呢？两个都依赖是肯定不行的，因为它们可能会有冲突的地方。这个时候就涉及到Maven中依赖传递对版本的选择问题。依赖传递在选择版本的时候首先是根据深度选择的。当一个项目同时经过不同的路径依赖于同一个组件时，会选择其深度最短的对应组件进行依赖。举例来说，假设A->B->C->D1.0，A->E->D2.0，那么这个时候A就会选择对D相对路径短的组件来进行依赖，也就是D2.0。那么当深度一样的时候Maven会如何选择呢？即A->B->D1.0和A->C->D2.0，这个时候Maven会如何选择A所依赖的D的版本呢？这种情况Maven会根据申明的依赖顺序来进行选择，先申明的会被作为依赖包。向前面这种情况，如果先申明对B的依赖，则A依赖的就是D1.0，如果先申明对C的依赖，则A依赖的就是D2.0。

使用exclusion排除依赖

假设有这样一种依赖关系，A->B->C，这个时候由于某些原因，我们不需要对C的依赖，但是我们又必须要对B的依赖，这个时候该怎么办呢？针对这种情况，Maven给我们提供了一个exclusion功能，我们可以在添加A对B的依赖时申明不需要引进B对C的依赖。具体做法如下：

<dependencies>
       <dependency>
              <groupId>groupB</groupId>
              <artifactId>artifactB</artifactId>
              <version>1.0</version>
              <exclusions>
                     <exclusion>
                            <groupId>groupC</groupId>
                            <artifactId>artifactC</artifactId>
                     </exclusion>
              </exclusions>
       </dependency>
       ...
</dependencies>

 

可选的依赖项

可选的依赖项表示可有可无，不一定需要的，它只是做一个标记。为了便于大家理解，我们先看这样一种情况，假设项目B依赖于项目C，这个时候我们把B对C的依赖利用optional标记为可选的，它意味着B中只有部分地方用到了C，并不是必须要的，当你依赖于B，但是又不需要使用到B的C功能时，可以不依赖于C。这样当A->B->C时，在建立项目A的时候将不会加入对C的依赖，因为C对B是可选的，我们不一定会用到C。但是在建立项目B的时候，Maven就会加入对C的依赖。也就是说这种标记为optional的依赖项对项目本身而言是没有什么影响的，它影响的是以该项目作为依赖项的其他项目，如这里的项目A。这种可选的依赖项有一个好处就是它会默认的作为exclusion项排除。

<project>
       <groupId>groupB</groupId>
       <artifactId>artifactB</artifactId>
       <version>1.0</version>
       <dependencies>
              <dependency>
                     <groupId>groupC</groupId>
                     <artifactId>artifactC</artifactId>
                     <version>1.0</version>
                     <optional>true</optional>
              </dependency>
              ...
       </dependencies>
</project>
 
<project>
       <groupId>groupA</groupId>
       <artifactId>artifactA</artifactId>
       <version>1.0</version>
       <dependencies>
              <dependency>
                     <groupId>groupB</groupId>
                     <artifactId>artifactB</artifactId>
                     <version>1.0</version>
              </dependency>
              ...
       </dependencies>
</project>

 

7.2     依赖项的作用域

在定义项目的依赖项的时候，我们可以通过scope来指定该依赖项的作用范围。scope的取值有compile、runtime、test、provided、system和import。

compile：这是依赖项的默认作用范围，即当没有指定依赖项的scope时默认使用compile。compile范围内的依赖项在所有情况下都是有效的，包括运行、测试和编译时。

runtime：表示该依赖项只有在运行时才是需要的，在编译的时候不需要。这种类型的依赖项将在运行和test的类路径下可以访问。

test：表示该依赖项只对测试时有用，包括测试代码的编译和运行，对于正常的项目运行是没有影响的。

provided：表示该依赖项将由JDK或者运行容器在运行时提供，也就是说由Maven提供的该依赖项我们只有在编译和测试时才会用到，而在运行时将由JDK或者运行容器提供。

system：当scope为system时，表示该依赖项是我们自己提供的，不需要Maven到仓库里面去找。指定scope为system需要与另一个属性元素systemPath一起使用，它表示该依赖项在当前系统的位置，使用的是绝对路径。比如官网给出了一个关于使用JDK的tools.jar的例子：

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>sun.jdk</groupId>
      <artifactId>tools</artifactId>
      <version>1.5.0</version>
      <scope>system</scope>
      <systemPath>${java.home}/../lib/tools.jar</systemPath>
    </dependency>
  </dependencies>
  ...
</project>

 

import：关于import的介绍，可以看后文中对引入依赖项的介绍。

7.3     dependencyManagement介绍

dependencyManagement主要有两个作用，一个是集中管理项目的依赖项，另一个就是控制使用的依赖项的版本。

7.3.1集中管理依赖项

看这样一种情况，我们有以下两个项目：

projectA

<project>
       <groupId>groupA</groupId>
       <artifactId>artifactA</artifactId>
       <version>1.0</version>
       <dependencies>
              <dependency>
                     <groupId>groupC</groupId>
                     <artifactId>artifactC</artifactId>
                     <version>1.0</version>
              </dependency>
              <dependency>
                     <groupId>groupD</groupId>
                     <artifactId>artifactD</artifactId>
                     <version>1.0</version>
              </dependency>
       </dependencies>
       ...
</project>

 

       ProjectB

<project>
       <groupId>groupB</groupId>
       <artifactId>artifactB</artifactId>
       <version>1.0</version>
       <dependencies>
              <dependency>
                     <groupId>groupC</groupId>
                     <artifactId>artifactC</artifactId>
                     <version>1.0</version>
              </dependency>
              <dependency>
                     <groupId>groupE</groupId>
                     <artifactId>artifactE</artifactId>
                     <version>1.0</version>
                     <type>bar</type>
              </dependency>
       </dependencies>
       ...
</project>

 

       从这两个项目中我们可以看出来，它们都依赖了artifactC，这样我们就可以创建一个新的项目，使用其dependencyManagement来统一管理这些依赖项。我们创建项目P来管理这些依赖项：

       projectP

<project>
       ...
       <dependencyManagement>
              <dependencies>
                     <dependency>
                            <groupId>groupC</groupId>
                            <artifactId>artifactC</artifactId>
                            <version>1.0</version>
                     </dependency>
                     <dependency>
                            <groupId>groupD</groupId>
                            <artifactId>artifactD</artifactId>
                            <version>1.0</version>
                     </dependency>
                     <dependency>
                            <groupId>groupE</groupId>
                            <artifactId>artifactE</artifactId>
                            <version>1.0</version>
                            <type>bar</type>
                     </dependency>
              </dependencies>
       </dependencyManagement>
       ...
</project>

 

       之后我们就可以这样来定义我们的projectA和projectB。

projectA

<project>
       <modelVersion>4.0</modelVersion>
       <groupId>groupA</groupId>
       <artifactId>artifactA</artifactId>
       <version>1.0</version>
       <dependencies>
              <dependency>
                     <groupId>groupC</groupId>
                     <artifactId>artifactC</artifactId>
              </dependency>
              <dependency>
                     <groupId>groupD</groupId>
                     <artifactId>artifactD</artifactId>
              </dependency>
       </dependencies>
       ...
</project>

 

 

       ProjectB

<project>
       <modelVersion>4.0</modelVersion>
       <groupId>groupB</groupId>
       <artifactId>artifactB</artifactId>
       <version>1.0</version>
       <dependencies>
              <dependency>
                     <groupId>groupC</groupId>
                     <artifactId>artifactC</artifactId>
              </dependency>
              <dependency>
                     <groupId>groupE</groupId>
                     <artifactId>artifactE</artifactId>
              <!--因为artifactE的类型不是默认的jar，所以这里需要指定依赖项的类型-->
                     <type>bar</type>
              </dependency>
       </dependencies>
       ...
</project>

 

从上面的定义我们可以看出，我们已经简化了projectA和projectB依赖项的定义，我们可以只在projectA和projectB中申明需要使用的依赖项，而不必指定其对应的版本和作用范围等信息，当指定了这些信息时子项目中的定义会覆盖父项目的dependencyManagement中的定义，否则将使用dependencyManagement中的定义。这样也可以很方便我们对依赖项的版本进行统一管理。

7.3.2控制依赖项使用的版本

看下面这样一种情况

projectA

<project>
       <modelVersion>4.0</modelVersion>
<groupId>groupA</groupId>
       <artifactId>artifactA</artifactId>
       <version>1.0</version>
       <packaging>pom</packaging>
       <dependencyManagement>
              <dependencies>
                     <dependency>
                            <groupId>groupA</groupId>
                            <artifactId>A</artifactId>
                            <version>1.5</version>
                     </dependency>
                     <dependency>
                            <groupId>groupA</groupId>
                            <artifactId>B</artifactId>
                            <version>1.0</version>
                     </dependency>
                     <dependency>
                            <groupId>groupA</groupId>
                            <artifactId>C</artifactId>
                            <version>1.0</version>
                     </dependency>
                     <dependency>
                            <groupId>groupA</groupId>
                            <artifactId>D</artifactId>
                            <version>1.6</version>
                     </dependency>
              </dependencies>
       </dependencyManagement>
       ...
</project>

 

 

       ProjectB

<project>
       <modelVersion>4.0</modelVersion>
       <groupId>groupB</groupId>
       <artifactId>artifactB</artifactId>
       <version>1.0</version>
       <packaging>pom</packaging>
       <dependencyManagement>
              <dependencies>
                     <dependency>
                            <groupId>groupA</groupId>
                            <artifactId>A</artifactId>
                            <version>1.0</version>
                     </dependency>
              </dependencies>
       </dependencyManagement>
       <dependencies>
              <dependency>
                     <groupId>groupA</groupId>
                     <artifactId>B</artifactId>
                     <version>1.8</version>
              </dependency>
              <dependency>
                     <groupId>groupA</groupId>
                     <artifactId>C</artifactId>
                     <scope>runtime</scope>
              </dependency>
       </dependencies>
       ...
</project>

 

       这样，当我们对projectB进行Maven操作的时候，依赖项A、B、C和D将会如下选择：

       当A是B或者C的一个依赖项的时候，projectB将使用的是A的1.0版本，因为A是申明在projectB的dependencyManagement中的，此外申明在dependencyManagement中的依赖项将比项目的依赖项的依赖项有更高的优先级，还有就是当前项目的申明将比其父项目的申明具有更高的优先级。

       依赖项B将使用版本1.8，因为依赖项B是直接申明在projectB中的，而且指定了版本为1.8，所以当前项目申明的版本会覆盖父项目的dependencyManagement中指定的版本。

       依赖项C将使用版本1.0，但是其作用范围将会是runtime。因为依赖项C也是直接申明在projectB中的，而且其没有指定自己所使用的版本，所以将使用其父项目的dependencyManagement中指定的版本。此外，其指定了自己所作用的范围是runtime，所以它会覆盖其父项目的dependencyManagement中所指定依赖项的默认的compile作用范围。

       依赖项D将使用版本1.6。当D是B或者C的一个依赖项的时候，projectB将使用D的1.6版本，因为项目D是申明在dependencyManagement中的，而且在dependencyManagement中申明的依赖项将比间接的依赖项具有更高的优先级。

7.4     引入依赖项

我们知道通过继承一个项目我们可以在子项目中很好的申明需要使用的父项目的dependencyManagement定义的依赖项。但是因为每个项目都只能申明唯一的一个父项目，这在某些时候就会限制我们的项目建立。为此Maven为我们提供了一种方法，那就是通过设定依赖项的scope为import。注意这种方式只有在Maven2.0.9以上的版本才能使用。

<project>
       ...
       <groupId>groupA</groupId>
       <artifactId>artifactA</artifactId>
       <version>1.0</version>
       <packaging>pom</packaging>
       <dependencyManagement>
              <dependencies>
                     <dependency>
                            <groupId>test</groupId>
                            <artifactId>A</artifactId>
                            <version>1.0</version>
                     </dependency>
                     <dependency>
                            <groupId>test</groupId>
                            <artifactId>B</artifactId>
                            <version>1.1</version>
                     </dependency>
                     <dependency>
                            <groupId>test</groupId>
                            <artifactId>C</artifactId>
                            <version>1.2</version>
                     </dependency>
                     <dependency>
                            <groupId>test</groupId>
                            <artifactId>D</artifactId>
                            <version>1.3</version>
                     </dependency>
              </dependencies>
       </dependencyManagement>
       ...
</project>

 

上面这个项目是用来统一管理项目的依赖项的。那么按照之前的那种继承机制，这个时候我们的项目artifactB是如下这样定义的：

<project>
       ...
       <parent>
              <groupId>groupA</groupId>
              <artifactId>artifactA</artifactId>
              <version>1.0</version>
       </parent>
       <groupId>groupA</groupId>
       <artifactId>artifactB</artifactId>
       <version>1.0</version>
       <packaging>pom</packaging>
       <dependencies>
              <dependency>
                     <groupId>test</groupId>
                     <artifactId>A</artifactId>
              </dependency>
              <dependency>
                     <groupId>test</groupId>
                     <artifactId>D</artifactId>
                     <scope>runtime</scope>
              </dependency>
       </dependencies>
       ...
</project>

 

       那么如果按照import这种形式的话，artifactB可以如下定义：

<project>
       ...
       <groupId>groupA</groupId>
       <artifactId>artifactB</artifactId>
       <version>1.0</version>
       <packaging>pom</packaging>
       <dependencyManagement>
              <dependencies>
                     <dependency>
                            <groupId>groupA</groupId>
                            <artifactId>artifactA</artifactId>
                            <version>1.0</version>
                            <type>pom</type>
                            <scope>import</scope>
                     </dependency>
              </dependencies>
       </dependencyManagement>
       <dependencies>
              <dependency>
                     <groupId>test</groupId>
                     <artifactId>A</artifactId>
              </dependency>
              <dependency>
                     <groupId>test</groupId>
                     <artifactId>D</artifactId>
                     <scope>runtime</scope>
              </dependency>
       </dependencies>
       ...
 
</project>

 

文章标签：
Java
Maven
容器
elim1
目录
相关文章
javaNice
|
7月前
|
Java Maven Spring
maven打包插件maven-jar-plugin与spring-boot-maven-plugin
该内容介绍了两个Maven打包插件：`spring-boot-maven-plugin`和`maven-jar-plugin`。`spring-boot-maven-plugin`是Spring Boot项目的默认打包工具，它会包含项目类文件、资源和依赖的jar，但不会解编译依赖。而`maven-jar-plugin`则用于创建普通JAR包，不包含依赖。文中还展示了两个插件打包后的效果差异，并强调了持续练习以掌握这些技能的重要性。
javaNice
287 0
老板这功能得加钱
|
7月前
|
Java Maven
Maven实战 Item4 -- Maven核心概念_maven junit version(1)
Maven实战 Item4 -- Maven核心概念_maven junit version(1)
老板这功能得加钱
41 0
落798.
|
7月前
|
IDE Java 程序员
【Maven从入门到如土】Maven概述
【Maven从入门到如土】Maven概述
落798.
61 0
ha_lydms
|
Java 应用服务中间件 测试技术
Maven简介
Maven简介
ha_lydms
341 0
greework
|
Java Maven
Maven的dependency中无版本号的可能情况
Maven的dependency中无版本号的可能情况
greework
642 0
唐家四少官微
|
XML Java Maven
Maven的dependency
Maven的dependency
唐家四少官微
143 0
游客wazjug5ieii4a
|
Java 测试技术 数据库连接
Maven实战
Maven是一个项目管理工具，将项目开发和管理过程抽象成一个项目对象模型(POM)：POM（Project Object Model）：项目对象模型！
游客wazjug5ieii4a
364 0
Maven实战
六月暴雪飞梨花
|
Dubbo Java fastjson
技术：Maven中dependency三剑客浅谈（二）
maven是一款项目管理工具软件，可以通过一小段信息来描述、管理、报告的管理工具。maven除了简单的程序构建外，还提供了高级的项目管理。Maven 是 Java 生态系统中最流行的构建工具之一，其核心特性之一是依赖管理。下面我们将描述和探索有助于管理 Maven 项目中的三剑客【groupId】、【artifactId】、【version】。
六月暴雪飞梨花
248 0
技术：Maven中dependency三剑客浅谈（二）
扎哇太枣糕
|
存储 Java Maven
Maven基础教程（一）
Maven基础教程（一）
扎哇太枣糕
125 0
Maven基础教程（一）
扎哇太枣糕
|
Java Maven
Maven基础教程（三）
Maven基础教程（三）
扎哇太枣糕
105 0
Maven基础教程（三）

热门文章

最新文章

  • 1
    CentOS7 yum的一次报错" 14: curl#56 - "Recv failure: Connection reset by peer" "
  • 2
    使用cProfile等工具来提高python的执行速度
  • 3
    四大触点，教你从“用户视角”构建数据分析体系
  • 4
    Spring-boot+Dubbo应用启停源码分析
  • 5
    Myeclipse常用优化1
  • 6
    Android开发学习笔记：数据存取之File浅析
  • 7
    Android Service完全解析，关于服务你所需知道的一切(下)
  • 8
    【妄言之言】致二十四岁的自己
  • 9
    oracle 11g adrci 工具使用方法
  • 10
    S3C2410-WinCE6.0-OAL的快速调试
  • 1
    《容器化赋能：C++人工智能模型部署的卓越之道》
    31
  • 2
    《C++与类脑芯片：开启人工智能硬件新征程》
    36
  • 3
    《C++与AMD ROCm：人工智能计算的强力引擎》
    34
  • 4
    《C++携手英特尔OpenVINO：加速人工智能推理新征程》
    29
  • 5
    《C++ 赋能强化学习：Q - learning 算法的实现之路》
    24
  • 6
    鸿蒙开发：ForEach中为什么键值生成函数很重要
    24
  • 7
    AI+脱口秀，笑点能靠算法创造吗
    32
  • 8
    「Mac畅玩鸿蒙与硬件45」UI互动应用篇22 - 评分统计工具
    103
  • 9
    AI客服会完全替代人工客服吗
    23
  • 10
    影智科技唐沐：人形是累赘，具身智能并不缺少落地场景
    26

    • 相关课程

    更多
  • 项目管理工具Maven学习

    • 相关电子书

    更多
  • 使用Spring.Initializr定制工程脚手架
  • 陈曦：使用Spring.Initializr定制工程脚手架
  • 低代码开发师（初级）实战教程

    • 推荐镜像

    更多
  • maven
  • eclipse
  • nodejs-release
    • 下一篇
    DataWorks