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>
相关推荐
资源介绍:Dependency Walker(依赖项查看器)是一款强大而实用的免费模块依赖性分析工具,专为Windows系统打造,旨在帮助开发者和系统管理员轻松解析和查看应用程序或DLL文件的依赖关系。 Dependency Walker通过...
本实例将详细介绍如何使用`SqlDependency`在Winform应用中监控SQL Server数据库,并在数据发生变化时触发前台页面的更新。 首先,`SqlDependency`是.NET Framework的System.Data.SqlClient命名空间中的一个类,它的...
`depends.chm`是软件的帮助文件,包含了关于如何使用Dependency Walker的详细信息,包括界面介绍、功能解释、常见问题解答等。开发者可以通过查阅这个文件来学习如何操作和理解工具的输出结果。 `depends.dll`则是...
"Dependency Walker 2.2.6000.0" 是一个在VStudio2005中常用的工具,专门用于分析Windows应用程序或动态链接库(DLLs)的依赖关系。这个工具可以帮助开发者理解和解决程序运行时由于依赖项缺失或不兼容而导致的问题...
**《Dependency Injection》**这本书不仅详细介绍了依赖注入的基础知识和技术细节,还深入探讨了如何有效地在实际项目中应用依赖注入。无论是对于刚开始接触这项技术的新手还是已经有一定经验的开发者来说,这本书都...
依赖注入(Dependency Injection,简称DI)是一种软件设计模式,它主要解决了对象之间的耦合问题,提高了代码的可测试性和可维护性。Manning出版社的"Dependency Injection"这本书深入探讨了这个主题,它可能是由...
在正式介绍依赖句法分析之前,有必要先了解依赖语法的基础概念。依赖语法是一种句法分析框架,它将句子看作是由一系列词构成的有向图,其中每个词都可能与其他词建立某种依赖关系。这种依赖关系反映了词语间的结构...
3. `README.md`:这是项目的基本介绍和指南,通常包含项目的目的、安装和使用方法、贡献指南等内容,对于理解和使用项目非常有用。 4. `jkm.png`:可能是一个项目的logo或者示意图,帮助用户直观了解项目内容。 5. `...
### 依赖注入(Dependency Injection)在.NET中的应用 #### 核心概念与定义 依赖注入(Dependency Injection,简称DI)是一种软件设计模式,主要用于降低组件之间的耦合度,提高代码的可测试性和可维护性。在.NET...
在描述部分提到,“This book is for general principle of dependency injection in software architecturing”,表明这本书是面向软件架构中依赖注入通用原则的介绍。这意味着读者将从本书中学到如何在软件设计中...
依赖注入(Dependency Injection,简称DI)是一种设计模式,用于实现软件模块间的解耦合。在.NET Core 2.0中,依赖注入是通过内置的服务容器来实现的,这种容器可以管理应用程序中的依赖关系和服务实例化。 #### 二...
Dependency-Check介绍 一、概述 Dependency-Check是由OWASP(Open Web Application Security Project)提供的一个实用开源程序,主要用于识别项目依赖项并检查是否存在任何已知的、公开披露的漏洞。这一工具在软件...
### 依赖注入在 Delphi 中的应用 ...总结而言,《Dependency Injection in Delphi》是一本非常实用的书籍,不仅介绍了依赖注入的基本概念,还提供了详细的实践指南,非常适合 Delphi 开发者学习和参考。
##### 增强依赖路径(Augmented Dependency Path, ADP) 为了充分利用依赖性信息,研究者们提出了增强依赖路径的概念。ADP由两个主要部分组成: - **最短依赖路径**:连接句子中两个实体之间的最短路径。 - **附加...
Java Dependency Viewer的介绍: Eclipse插件Java Dependency Viewer是一个为Java项目提供依赖关系可视化功能的工具。 在复杂的Java项目中,理解和分析类与类之间、包与包之间的依赖关系是非常有用的。Java ...
例如,在介绍Warp Persist时,提到了它是如何为Guice提供了JPA集成和声明式事务支持的。这些具体的案例对于理解依赖注入的实际应用场景和最佳实践非常有帮助。 通过本书的学习,开发者不仅可以深入了解依赖注入的...
- 该标题明确指出了论文的主题是介绍了一种基于神经网络的快速且准确的依存关系解析器。 #### 描述解读: - **描述**:“Danqi Chen的A Fast and Accurate Dependency Parser using Neural Networks” - 描述重复...
今天,我们将详细介绍 Maven 依赖管理机制中的两个重要概念:dependencies 和 dependencyManagement。 dependencies dependencies 是 Maven 项目中最基本的依赖管理机制。它定义了项目中需要的依赖项,包括 jar 包...