前文(Maven填坑记一)以持续集成为例，引申出了maven命令的正确使用方法，并简单介绍了一下maven的基本概念。今天我们从一个具体的pom文件入手来了解一下maven的其他概念以及面试中常见的一些问题。

Maven的依赖

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>
 <parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>2.1.0.RELEASE</version>
 <relativePath/> 
 </parent>
 <groupId>com.bancheng</groupId>
 <artifactId>demoTest</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <name>demoTest</name>
 <description>Demo project for Spring Boot</description>
 <properties>
 <spring.version>4.2.1</spring.version>
 </properties>
 <dependencies>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 </dependency>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-test</artifactId>
 <version>${spring.version}</version>
 <scope>test</scope>
 </dependency>
 </dependencies>
</project>

上面是一个标准的pom文件，其中的坐标部分，前文已经涉及过，今天就不展开了，我们来重点关于一下<dependencies></dependencies>包含的内容。这部分内容在maven中被称为依赖，定义了该项目需要引入的外部jar包，在实际构建过程中，会遵循上文的依赖搜索顺序，将相应的jar包打入最终的项目jar包或者war包里面。

接下来让我们看一下依赖可能涉及的具体元素吧。

• dependencies：一个 pom.xml 文件中只能存在一个这样的标签。用来管理依赖的总标签。
• dependency:包含在dependencies标签中，可以有无数个，每一个表示一个依赖
• groupId,artifactId和version：依赖的基本坐标，对于任何一个依赖来说，基本坐标是最重要的，maven根据坐标才能找到需要的依赖。如果一个依赖在项目中需要引用多次，对于其版本定义可以采用变量的方式，具体请参考上面。
• type：依赖的类型，对应于项目坐标定义的packaging。大部分情况下，该元素不必声明，其默认值是jar。
• scope：依赖的范围，默认值是 compile。
• optional：标记依赖是否可选。
• exclusions：用来排除传递性依赖。

项目中多次引用相同的类包，版本相同，可以采用上面变量的方式统一声明，那如果版本不相同呢，特别是不同类包的间接依赖导致的版本不一致，maven是如何解决对应版本冲突的呢？

这就必然需要定义一个依赖传递规则。

1．第一声明者优先原则

2．路径近者优先原则

可以通过mvn dependency:tree命令生成项目的依赖树，如下图所示：

该依赖树的根节点是本项目生成的jar包，接下来是本项目直接依赖的类包，其他是本项目直接依赖类包依赖的间接类包，这三者形成了一个不同层级的树状结构。依据上面的两个原则，如果发生冲突的类包是在同一层级，那么优先声明的类包版本生效，如果是在不同层级的类包，那么离根节点层级更近的类包版本生效。当然这种方式不够直观，最好的方法还是通过exclusions标签来显示排除，如下图所示。

<exclusions> 
 <exclusion> 
 <artifactId>unitils-database</artifactId> 
 <groupId>org.unitils</groupId> 
</exclusion> </exclusions> 

Maven的依赖范围

上面的依赖中用到的scope标签的值是test，这个有什么特殊含义呢？

1. compile:编译依赖，默认的依赖方式，在编译（编译项目和编译测试用例）、运行测试用例、运行（项目实际运行）三个阶段都有效。

2. test:测试依赖，只在编译测试用例和运行测试用例有效，典型的有JUnit。

3. provided:对于编译和测试有效，不会打包进发布包中，典型的例子为servlet-api,一般的web工程运行时都使用容器的servlet-api，如tomcat容器。

4. runtime:只在运行测试用例和实际运行时有效，典型的是jdbc驱动jar包。

5. system: 不从maven仓库获取该jar,而是通过systemPath指定该jar的路径。

6. import: 用于一个dependencyManagement对另一个dependencyManagement的继承。

常见的面试题

Maven常见的面试题有哪些呢？

Q：dependencies和dependencyManagement，plugins和pluginManagement有什么区别呢？

A：dependencyManagement是表示依赖jar包的声明，即使在项目中的dependencyManagement下声明了依赖，maven不会直接加载该依赖，但是其声明可以被继承。一个常用的使用案例是父子项目的时候，应用于父项目。之后在在子项目中的dependencies节点可以只配置groupid和artifactid就可以完成类包的引用。类似的还有plugins和pluginManagement。

Q：如何制定JDK版本

A：有两种方式，一种是通过properties方式，如下面所示：

<properties>
 <maven.compiler.source>1.8<maven.compiler.source>
 <maven.compiler.target>1.8</maven.compiler.target>
<properties>

一种是使用maven-compiler-plugin插件，并制定source和target版本，如下面所示：

<build>
 <plugins>
 <plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactedId>maven-complier-plugin</artifactedId>
 <version>3.3</version>
 <configuration>
 <source>1.8</source>
 <target>1.8</target>
 </configuration>
 </plugin>
 </plugins>
</build>

Q：如何避免将dependency打包到构件中

A：如上文所述，将<scope>标签的值设为provided,只会在编译和测试阶段生效。

以上介绍了依赖的传递规则、范围及常见的面试题，希望对大家有帮助，更多精彩，请持续关注哦。