Maven依赖配置和依赖范围

Maven依赖配置

一个dependency的声明可以包含以下元素：

<dependencies>
    <dependency>
        <groupId>org.apache.kafka</groupId>
        <artifactId>kafka-clients</artifactId>
        <version>0.8.2.2</version>
        <scope>compile</scope>
        <optional>false</optional>
        <exclusions>
            <exclusion>
                <groupId>org.apache.zookeeper</groupId>
                <artifactId>zookeeper</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

• groupId+artifactId+version构成了依赖的基本坐标，Maven根据坐标才能找到依赖。
• scope定义了依赖的范围，默认是compile。
• optional定义了是否为可选依赖，默认是false。
• exclusion用来排除传递性依赖。

Maven依赖范围

Maven有以下几种依赖范围：

• compile：编译依赖范围，使用此依赖范围对于编译、测试、运行三种classpath都有效，即在编译、测试和运行时都要使用该依赖jar包；
• test：测试依赖范围，只对测试有效，表明只在测试的时候需要，在编译和运行时将无法使用该类依赖，如 junit；
• provided：已提供依赖范围。编译和测试有效，运行无效。如servlet-api，在项目运行时，tomcat等容器已经提供，无需Maven重复引入；
• runtime：运行时依赖范围。测试和运行有效，编译无效。如 jdbc 驱动实现，编译时只需接口，测试或运行时才需要具体的 jdbc 驱动实现；
• system：系统依赖范围，使用system范围的依赖时必须通过systemPath元素显示地指定依赖文件的路径，不依赖Maven仓库解析，所以可能会造成建构的不可移植，谨慎使用。

传递依赖

• 一个工程有一个compile依赖范围的spring-core依赖，而spring-core有一个compile依赖范围的commons-loggings依赖，则commons-loggings是本工程的传递性依赖。传递依赖就是scope标签，默认compile。

• 几种依赖范围的组合下，会有如下的依赖效果： 
  

• 传递依赖原则 
  

可选依赖

举例来说，一个类似hibernate的项目，它支持对mysql、oracle等各种数据库的支持，但是在引用这个项目时，我们可能只用到其对mysql的支持，此时就可以在这个项目中配置可选依赖。可选依赖就是optional标签，默认false。

<dependencies>
  <dependency>
    <groupId>sample.ProjectB</groupId>
    <artifactId>Project-B</artifactId>
    <version>1.0</version>
    <scope>compile</scope>
    <optional>true</optional>
  </dependency>
</dependencies>

假设以上配置是项目A的配置，即：Project-A –> Project-B。在编译项目A时，是可以正常通过的。

如果有一个新的项目X依赖A，即：Project-X -> Project-A，此时项目X就不会依赖项目B了。如果项目X用到了涉及项目B的功能，那么就需要在X项目的pom.xml中重新配置对项目B的依赖。

排除依赖 
Maven的传递性依赖会隐式地传入很多依赖，例如kafka-clients依赖了zookeeper，但我们想去除对zookeeper包的引用，那么就需要用exclusion元素了。见最上面的依赖配置。

转自：https://blog.csdn.net/peerless_hero/article/details/57428763