《Maven实战》笔记-2-坐标和依赖

一、依赖范围

Maven在编译项目主代码的时候，需要使用一套classpath——编译classpath；

在编译和执行测试的时候，使用另一套classpath——测试classpath；

实际运行Maven项目的时候，又会使用一套classpath——运行classpath。

【依赖范围】就是用来控制依赖与这三种classpath的关系，Maven有以下几种依赖范围：

1、compile：编译依赖范围

默认，对编译、测试、运行三种classpath都有效，如spring-core.

2、test：测试依赖范围

只对测试classpath有效，如JUnit。

3、provided：已提供依赖范围

对编译和测试classpath有效，但对运行时无效，如Tomcat容器的servlet-api，编译和测试项目需要，但运行项目时，容器已经提供。

4、runtime：运行时依赖范围

对于测试和运行classpath有效，但在编译主代码时无效，如JDBC驱动实现，项目主代码的编译只需要JDK提供的JDBC接口，只有在执行测试或运行时才需要实现上述接口的具体JDBC驱动。

5、system：系统依赖范围

该依赖于三种classpath的关系，和provided依赖范围完全一致，但往往与本机系统绑定，可能造成构建的不可移植，因此应该谨慎使用。

6、import：导入依赖范围

该依赖范围不会对三种classpath产生实际的影响。

 

二、传递性依赖

如图，若A有一个compile范围的依赖B，B有一个compile范围的依赖C，那么C就会成为A的compile范围依赖。

C是A的一个传递性依赖。

若：

A对于B是第一直接依赖；

B对于C是第二直接依赖；

A对于C是传递性依赖；

则：

 

其中，左一列是第一直接依赖范围，上一行是第二直接依赖范围，中间就是传递性依赖的范围。

 

三、可选依赖

 

 

使用optional元素表示两个依赖为可选依赖，它们只会对B产生影响，当其他项目依赖于B的时候，这两个依赖不会被传递，就需要在A中显示地声明出来mysql-connector-java、或postgresql。

在理想的情况下，是不应该使用可选依赖的！！

 

 

四、排除依赖

项目A依赖于项目B，但是由于一些原因，不想引入传递性依赖C，而是自己显示地声明对于项目C的版本依赖，可在代码中使用exclusions元素声明排除依赖。exclusions可以包含一个或者多个exclusion子元素，且exclusion只需要groupId和artifactId。

五、归类依赖

例如，对Spring Framework的依赖来自同一项目的不同模块，所有这些依赖的版本都是相同的，如果将来需要升级Spring Framework，这些依赖的版本会一起升级。

 

六、优化依赖

dependency:list

dependency:tree

dependecy:analyze

 

 

 

 

来自为知笔记(Wiz)

转载于:https://www.cnblogs.com/myitroad/p/6131208.html