【maven】依赖中名词解释及使用方式

写在前面：pom.xml是maven依赖配置选项的地方。

1、概念介绍 

一、Dependencies：是可选依赖（Optional Dependencies） 

二、Exclusions：是依赖排除（Dependency Exclusions） 

三、dependencyManagement ：统一多模块的依赖版本

每个依赖节点<dependency>都由三个子节点组成：

• <groupId> ： 该依赖库所属的组织名称
• <artifactId> ： 依赖的库名
• <version> ： 依赖的库版本

在POM 4中，<dependency> 中还引入了<scope> ，它主要管理依赖的部署。目前<scope> 可以使用5个值：

• compile，缺省值，适用于所有阶段，会随着项目一起发布。
• provided，类似compile，期望JDK、容器或使用者会提供这个依赖。如servlet.jar。
• runtime，只在运行时使用，如JDBC驱动，适用运行和测试阶段。
• test，只在测试时使用，用于编译和运行测试代码。不会随项目发布。
• system，类似provided，需要显式提供包含依赖的jar，Maven不会在Repository中查找它。

 

2.使用方式及为什么这么用

一、Dependencies ：
（1）当一个项目A依赖另一个项目B时，项目A可能很少一部分功能用到了项目B，此时就可以在A中配置对B的可选依赖。举例来说，一个类似hibernate的项目，它支持对mysql、oracle等各种数据库的支持，但是在引用这个项目时，我们可能只用到其对mysql的支持，此时就可以在这个项目中配置可选依赖。 

（2）配置可选依赖的原因： 
1）节约磁盘、内存等空间； 
2）避免license许可问题； 
3）避免类路径问题，等等。 
（3）示例：

<project>
  ...
  <dependencies>
    <!-- declare the dependency to be set as optional -->
    <dependency>
      <groupId>sample.ProjectB</groupId>
      <artifactId>Project-B</artifactId>
      <version>1.0</version>
      <scope>compile</scope>
      <optional>true</optional> <!-- value will be true or false only -->
    </dependency>
  </dependencies>
</project>

假设以上配置是项目A的配置，即：Project-A –> Project-B。在编译项目A时，是可以正常通过的。如果有一个新的项目X依赖A，即：Project-X -> Project-A。此时项目X就不会依赖项目B了。如果项目X用到了涉及项目B的功能，那么就需要在pom.xml中重新配置对项目B的依赖。假设A->B, B->x（可选）, B->y（可选）。这里由于x，y是可选依赖，依赖不会传递，x，y将不会对a有任何影响。

总结一句话：依赖不具有传递性，新项目使用某依赖时，需要重新引入。

二、Exclusions 
（1）当一个项目A依赖项目B，而项目B同时依赖项目C，如果项目A中因为各种原因不想引用项目C，在配置项目B的依赖时，可以排除对C的依赖。 
（2）示例（假设配置的是A的pom.xml，依赖关系为：A –> B; B –> C）：

<project>
  ...
  <dependencies>
    <dependency>
      <groupId>sample.ProjectB</groupId>
      <artifactId>Project-B</artifactId>
      <version>1.0</version>
      <scope>compile</scope>
      <exclusions>
        <exclusion>  <!-- declare the exclusion here -->
          <groupId>sample.ProjectC</groupId>
          <artifactId>Project-C</artifactId>
        </exclusion>
      </exclusions> 
    </dependency>
  </dependencies>
</project>

相对于dependencyManagement，父类中直接使用所有生命在dependencies里的依赖都会自动引入，并默认被所有的子项目继承。

如果依赖只在某个子项目中使用，则可以在子项目的pom.xml中直接引入，防止父pom的过于臃肿。

三、dependencyManagement

（1）为什么要用dependencyManagement？

如果你的项目有多个子模块，而且每个模块都需要引入依赖，但为了项目的正确运行，必须让所有的子项目(以下子项目即指子模块)使用依赖项的统一版本，才能保证测试的和发布的是相同的结果。那么如何保证模块之间的版本是一致的呢？

Maven 使用 dependencyManagement 来统一模块见的依赖版本问题。

在父项目的POM文件中，我们会使用到dependencyManagement元素。通过它来管理jar包的版本，让子项目中引用一个依赖而不用显示的列出版本号。Maven会沿着父子层次向上走，直到找到一个拥有dependencyManagement元素的项目，然后它就会使用在dependencyManagement元素中指定的版本号。
 

（）示例

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.XXXX</groupId>
                <artifactId>inf-B</artifactId>
                <version>1.2.10</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

dependencies与dependencyManagement 区别总结：

1、dependencies即使在子项目中不写该依赖项，那么子项目仍然会从父项目中继承该依赖项（全部继承）

2、dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要用的依赖。如果不在子项目中声明依赖，是不会从父项目中继承下来的；只有在子项目中写了该依赖项，并且没有指定具体版本，才会从父项目中继承该项，并且version和scope都读取自父pom;另外如果子项目中指定了版本号，那么会使用子项目中指定的jar版本。

依赖的版本不能统一时，依赖传递的原则：
1、在工程的依赖树上，深度越浅，越被有限选择。

2、若两个依赖包处于依赖树上的同一层，则谁在前选择谁。
 

其他：

1.maven的依赖调解有两大原则：路径最近者优先；第一声明者优先。 

2.maven的归类依赖，在pom文件中，我们经常会看到：

<dependency>
    <groupId>org.scala-lang</groupId>
    <artifactId>scala-library</artifactId>
    <version>${scala.version}</version>
</dependency>

里面的${scala.version}是由下面语句统一配置：定义如下属性值后，maven会将pom中的所有的${scala.version}替换成实际值2.3.0

<properties>
<scala.version>2.3.0<scala.version>
</properties>

3.在修改完pom文件后，会重新加入依赖，对于一些需要提交的到机器上的作业而言，需要将其进行打包，即package，否则提交的作业还是依赖原来的包。比如在美团，有一个hadoop的中转站工具，名曰hope，在提交任务的时候，如果修改pom，则需要先进行hope package demo.hope然后再提交。

 

参考：

1.https://blog.csdn.net/eff666/article/details/51991465

2.https://blog.csdn.net/OiteBody/article/details/70882940