`
234390216
  • 浏览: 10238769 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
博客专栏
A5ee55b9-a463-3d09-9c78-0c0cf33198cd
Oracle基础
浏览量：462901
Ad26f909-6440-35a9-b4e9-9aea825bd38e
springMVC介绍
浏览量：1775984
Ce363057-ae4d-3ee1-bb46-e7b51a722a4b
Mybatis简介
浏览量：1398756
Bdeb91ad-cf8a-3fe9-942a-3710073b4000
Spring整合JMS
浏览量：395157
5cbbde67-7cd5-313c-95c2-4185389601e7
Ehcache简介
浏览量：680175
Cc1c0708-ccc2-3d20-ba47-d40e04440682
Cas简介
浏览量：531148
51592fc3-854c-34f4-9eff-cb82d993ab3a
Spring Securi...
浏览量：1185029
23e1c30e-ef8c-3702-aa3c-e83277ffca91
Spring基础知识
浏览量：468825
4af1c81c-eb9d-365f-b759-07685a32156e
Spring Aop介绍
浏览量：151494
2f926891-9e7a-3ce2-a074-3acb2aaf2584
JAXB简介
浏览量：68344
社区版块
存档分类
最新评论

Maven简介（六）——Dependency

MavenDependency依赖 
阅读更多

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>

 

分享到：
| Maven简介（五）——pom.xml
评论
1 楼 liu765023051 2016-04-10  
总结的很好，感谢！
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

    Maven仓库的压缩包,解压后将aspectjweaver-1.9.6.jar替换到自己的Maven仓库即可

    在本主题中，我们关注的是一个特定的库——AspectJ Weaver，版本为1.9.6，它是AspectJ框架的核心组件，用于在运行时对Java代码进行编织（weaving）以实现切面编程（Aspect-Oriented Programming, AOP）。现在让我们...

    maven 中引入依赖的包

    首先，理解Maven的核心概念——`pom.xml`。这是每个Maven项目的心脏，它定义了项目的配置信息，包括项目的基本信息（如groupId、artifactId、version），以及项目依赖的外部库。当你需要引入一个新的依赖包时，你...

    eclipse中maven工程建maven-course项目

    本教程将详细阐述如何在Eclipse中创建一个基于Maven的项目——"maven-course"，并实现基本的CRUD（创建、读取、更新、删除）功能，利用JSP、MyBatis接口绑定以及MVC+三层架构的设计模式进行实践操作。 首先，我们...

    maven配置文件和仓库

    首先，我们来看看Maven的核心配置文件——`settings.xml`。这个文件位于用户的`.m2`目录下，它定义了Maven的全局配置，包括本地仓库路径、远程仓库列表、镜像设置等。`settings.xml`中的`localRepository`元素指定了...

    maven3.0.5

    2. **生命周期**：Maven有三个主要的生命周期阶段——清理、默认和站点。清理阶段包括`clean`目标，用于删除生成的目标文件；默认阶段包括`compile`、`test`、`package`、`install`和`deploy`目标，分别对应编译、...

    Maven的HelloWorld程序

    然后，我们来看Maven的项目描述文件——`pom.xml`。这是Maven的核心，包含了项目的元数据、依赖关系、构建指令等。对于HelloWorld程序，`pom.xml`通常会包含以下内容： ```xml &lt;project xmlns="http://maven.apache...

    Maven常用插件整理.docx

    9. Maven Dependency Plugin Dependency Plugin提供了许多与依赖相关的功能，如分析依赖树、提取依赖、打包依赖等。 10. Maven Install Plugin Install Plugin将构建结果安装到本地Maven仓库，供本地项目引用。 在...

    手动创建maven工程

    首先，我们要理解Maven的核心概念——Project Object Model (POM)。POM是Maven项目的基本配置单元，包含了项目信息、构建指令、依赖管理等关键元素。在`pom.xml`文件中，你可以声明项目所依赖的库，设置编译和打包...

    maven-3.2.5 java

    2. **依赖管理（Dependency Management）**：Maven通过POM文件管理项目的依赖关系，自动下载并管理库文件，避免了手动处理jar包的繁琐工作。 3. **插件（Plugins）**：Maven使用插件来执行构建任务，如编译、测试、...

    maven教程，分模块构建及私服搭建

    5. **依赖管理**：Maven的依赖管理能处理版本冲突，通过设定dependencyManagement可以统一管理所有子模块的依赖版本。 通过本教程的学习，你将掌握如何利用Maven进行模块化开发，以及如何构建和管理私有仓库，提升...

    Spring in Action 使用Maven 构建Spring 工程

    首先，我们来理解Spring框架的核心概念——依赖注入（Dependency Injection，简称DI）。Spring通过DI模式，解耦了组件之间的依赖关系，使得组件可以独立地进行单元测试和组装。在Maven构建的Spring工程中，我们会在`...

    Maven的安装教程及工具包

    首先，我们来了解Maven的核心概念——POM（Project Object Model）。POM是一个XML文件，包含了项目的配置信息，如项目依赖、构建目标、插件配置等。它是Maven理解并管理项目的基础。 **Maven的安装步骤：** 1. **...

    使用 Maven 管理 Seam 项目

    Maven通过使用一个中心化的配置文件——pom.xml，来定义项目的构建过程和依赖关系。在Seam项目中，我们首先需要在pom.xml中声明Seam的依赖项，包括核心库、相关的模块以及它们的版本。例如，我们需要添加如下的依赖...

    精简maven整合百度富文本编辑器Ueditor

    本教程将详细介绍如何使用Maven这一流行的构建工具，整合百度的富文本编辑器——Ueditor，以便在Java Web项目中实现高效的文本编辑功能。Maven是一个强大的项目管理工具，能够帮助我们管理和构建Java项目，而Ueditor...

    Maven2 5分钟学习教程(中文)----maven2 官方文档翻译

    **Maven 2 5分钟学习教程(中文)——官方文档翻译** Maven是一个强大的Java项目管理工具，它简化了构建、依赖管理和项目生命周期的管理。这篇5分钟学习教程是Maven 2官方文档的中文翻译，旨在帮助初学者快速理解和...

    eclipse maven插件

    Eclipse Maven插件提供了一些诊断工具，如"Dependency Hierarchy"视图，帮助开发者理解和解决这些问题。 7. **与其他工具集成** Eclipse Maven插件还可以与其他Eclipse插件（如Spring Tool Suite）集成，为更复杂...

    maven下整合ssh源码

    在IT行业中，SSH框架是Java开发中常用的三大框架——Spring、Struts和Hibernate的组合，它们各自负责不同的职责，Spring管理应用的业务层和依赖，Struts处理MVC模式中的视图与控制，Hibernate则专注于数据持久化。...

    Maven类包冲突终极解决小技若干

    这种依赖传递性导致了类包冲突的可能性——即同一个类库的不同版本在同一项目中出现的情况。 例如，假设项目 A 依赖于项目 B 和 C，而项目 B 又依赖于库 X 的 1.0 版本，项目 C 依赖于库 X 的 2.0 版本。在这种情况...

Magicbox
Global site tag (gtag.js) - Google Analytics