怎样创建网站或网页,今天邵阳最新消息,建设公司网站新闻素材管理,四川专门做招聘酒的网站文章目录 依赖的配置依赖范围传递性依赖传递性依赖和依赖范围依赖调解可选依赖最佳实践排除依赖归类依赖优化依赖 依赖的配置
依赖会有基本的groupId、artifactld 和 version等元素组成。其实一个依赖声明可以包含如下的一些元素#xff1a;
project
...depende… 文章目录 依赖的配置依赖范围传递性依赖传递性依赖和依赖范围依赖调解可选依赖最佳实践排除依赖归类依赖优化依赖 依赖的配置
依赖会有基本的groupId、artifactld 和 version等元素组成。其实一个依赖声明可以包含如下的一些元素
project
...dependenciesdependencygroupId.../groupIdartifactId.../artifactIdversion.../versiontype.../typescope.../scopeoptional.../optionalexclusionsexclusion.../exclusion.../exclusions/dependency.../dependencies
...
/project其中每个标签的意思直接参考Maven实战.pom.xml标签说明中的dependencies处。
依赖范围
参考Maven实战.pom.xml标签说明中的scope处。
传递性依赖
考虑一个基于 Spring Framework 的项目如果不使用 Maven那么在项目中就需要手动下载相关依赖。由于 Spring Framework 又会依赖于其他开源类库因此实际中往往会下载一个很大的如 spring-framework-2.5.6-with-dependencies.zip 的包这里包含了所有 SpringFramework 的 jar 包以及所有它依赖的其他 jar 包。这么做往往就引人了很多不必要的依赖。另一种做法是只下载 spring-framework-2.5.6.zip 这样一个包这里不包含其他相关依赖到实际使用的时候再根据出错信息或者查询相关文档加入需要的其他依赖。很显然这也是一件非常麻烦的事情。
Maven 的传递性依赖机制可以很好地解决这一问题。假如有一个项目 account-email该项目有一个 org.springframework : spring-core:2.5.6 的依赖而实际上 spring-core 也有它自己的依赖我们可以直接访问位于中央仓库的该构件的 POM也就是 spring-core-2.5.6.pom。该文件包含了一个 commons-logging 依赖如下。
dependencygroupIdcommons-logging/groupIdartifactIdcommons-logging/artifactIdversion1.1.1/versionscopecompile/scope
/dependency该依赖的 scope 是 compile或者没有声明依赖范围则依赖范围就是默认的 compie。同时项目 account-email 中spring-core 的依赖范围我们也设置为 compile。那么此时 commons-logging 就会成为 account-email 的 compile 范围依赖commons-logging 是 account-email 的一个传递性依赖。如下图 有了传递性依赖机制在使用 SpringFramework 的时候就不用去考虑它依赖了什么也不用担心引人多余的依赖。Maven 会解析各个直接依赖的 POM将那些必要的间接依赖以传递性依赖的形式引人到当前的项目中。
传递性依赖和依赖范围
依赖范围不仅可以控制依赖与三种 classpah 的关系还对传递性依赖产生影响。上面的例子中account-email 对于 spring-core 的依赖范围是 compilespring-core 对于 commons-logging 的依赖范围是 compile那么 account-email 对于 commons-logging 这一传递性依赖的范围也就是 compile。
假设A依赖于BB依赖于C我们说A对于B是第一直接依赖B对于C是第二直接依赖A对于C是传递性依赖。第一直接依赖的范围和第二直接依赖的范围决定了传递性依赖的范围如下图所示最左边一列表示第一直接依赖范围最上面一行表示第二直接依赖范围中间的交叉单元格则表示传递性依赖范围。 为了能够更好地理解这里再举个例子。account-email 项目有一个com.icegreen : greenmail : 1.3.1b 的直接依赖我们说这是第一直接依赖其依赖范围是 test而 greenmail 又有一个 javax.mail : mail : 1.4 的直接依赖我们说这是第二直接依赖其依赖范围是 compile。显然javax.mail : mail : 1.4 是 account-email 的传递性依赖对照上图可以知道当第一直接依赖范围为 test第二直接依赖范围是 compile 的时候传递性依赖的范围是 test因此 javax.mail : mail : 1.4 是 account-email 的一个范围是 test 的传递性依赖。
仔细观察一下上图可以发现这样的规律
当第二直接依赖的范围是 compile 的时候传递性依赖的范围与第一直接依赖的范围一致当第二直接依赖的范围是 test 的时候依赖不会得以传递当第二直接依赖的范围是 provided的时候只传递第一直接依赖范围也为 provided 的依赖且传递性依赖的范围同样为 provided;当第二直接依赖的范围是 runtime 的时候传递性依赖的范围与第一直接依赖的范围一致但 compile 例外此时传递性依赖的范围为runtime。
依赖调解
Maven 引人的传递性依赖机制一方面大大简化和方便了依赖声明另一方面大部分情况下我们只需要关心项目的直接依赖是什么而不用考虑这些直接依赖会引入什么传递性依赖。但有时候当传递性依赖造成问题的时候我们就需要清楚地知道该传递性依赖是从哪条依赖路径引入的。
例如项目 A 有这样的依赖关系A - B - C - X(1.0)、A - D - X(2.0)X 是 A 的传递性依赖但是两条依赖路径上有两个版本的 X那么哪个 X 会被 Maven 解析使用呢两个版本都被解析显然是不对的因为那会造成依赖重复因此必须选择一个。
Maven依赖调解(Dependency Mediation)的第一原则是路径最近者优先。该例中 X(1.0) 的路径长度为3而 X(2.0) 的路径长度为2因此 X(2.0) 会被解析使用。
依赖调解第一原则不能解决所有问题比如这样的依赖关系A - B - Y(1.0)、A - C - Y(2.0)Y(1.0) 和 Y(2.0) 的依赖路径长度是一样的都为2。那么到底谁会被解析使用呢
在 Maven 2.0.8 及之前的版本中这是不确定的但是从 Maven2.0.9 开始为了尽可能避免构建的不确定性Maven 定义了依赖调解的第二原则第一声明者优先。在依赖路径长度相等的前提下在 POM 中依赖声明的顺序决定了谁会被解析使用顺序最靠前的那个依赖优胜。该例中如果 B 的依赖声明在 C 之前那么 Y(1.0) 就会被解析使用。
可选依赖
假设有这样一个依赖关系项目 A 依赖于项目 B项目 B 依赖于项目 X 和 YB 对于 X 和 Y 的依赖都是可选依赖A - B、B - X(可选)、B - Y(可选)。根据传递性依赖的定义如果所有这三个A 对 B 的依赖、B 对 X 的依赖 以及 B 对 Y 的依赖依赖的范围都是 compile那么 X、Y 就是 A 的 compile 范围传递性依赖。然而由于这里 X、Y 是可选依赖依赖将不会得以传递。换句话说X、Y 将不会对 A 有任何影响如下图所示。 为什么要使用可选依赖这一特性呢可能项目 B 实现了两个特性其中的特性一依赖于 X特性二依赖于 Y而且这两个特性是互斥的用户不可能同时使用两个特性。比如 B 是一个持久层隔离工具包它支持多种数据库包括 MSQL、PostgreSQL等。在构建这个工具包的时候需要这两种数据库的驱动程序但在使用这个工具包的时候只会依赖一种数据库。
项目 B 的依赖声明如下
dependenciesdependencygroupIdmysql/groupIdartifactIdmysql-connector-java/artifactIdversion5.1.10/versionoptionaltrue/optional/dependencydependencygroupIdpostgresql/groupIdartifactIdpostgresql/artifactIdversion8.4-701.jdbc3/versionoptionaltrue/optional/dependency
/dependencies上述 XML 代码片段中使用optional元素表示 mysql-connector-java和 postgresql 这两个依赖为可选依赖它们只会对当前项目 B 产生影响当其他项目依赖于B的时候这两个依赖不会被传递。因此当项目 A 依赖于项目 B 的时候如果其实际使用基于MySOL数据库那么在项目 A 中就需要自己显式地声明 mysql-connector-java 这一依赖。
最后关于可选依赖需要说明的一点是在理想的情况下是不应该使用可选依赖的。前面我们可以看到使用可选依赖的原因是某一个项目实现了多个特性在面向对象设计中有个单一职责性原则意指一个类应该只有一项职责而不是糅合太多的功能。这个原则在规划 Maven 项目的时候也同样适用。在上面的例子中更好的做法是为MYSQL 和 PostgreSQL 分别创建一个 Maven 项目基于同样的groupld 分配不同的 artifactld在各自的 POM 中声明对应的JDBC驱动依赖而且不使用可选依赖用户则根据需要选择使用哪个驱动的 Maven 项目的构件。由于传递性依赖的作用就不用再声明 JDBC 驱动依赖。
最佳实践
Maven 依赖涉及的知识点比较多在理解了主要的功能和原理之后最需要的当然就是经验总结了这里归纳了一些使用 Maven 依赖常见的技巧方便用来避免和处理很多常见的问题。
排除依赖
传递性依赖会给项目隐式地引入很多依赖这极大地简化了项目依赖的管理但是有些时候这种特性也会带来问题。例如当前项目有一个第三方依赖而这个第三方依赖由于某些原因依赖了另外一个类库的 SNAPSHOT 版本那么这个 SNAPSHOT 就会成为当前项目的传递性依赖而 SNAPSHOT 的不稳定性会直接影响到当前的项目。这时就需要排除掉该 SNAPSHOT并且在当前项目中声明该类库的某个正式发布的版本。还有一些情况你可能也想要替换某个传递性依赖比如 Sun JTA APIHibernate 依赖于这个 JAR但是由于版权的因素该类库不在中央仓库中而 Apache Geronimo 项目有一个对应的实现。这时你就可以排除 Sun JAT API再声明 Geronimo 的 JTA API 实现示例代码如下
dependenciesdependencygroupIdcom.juvenxu.mvnbook/groupIdartifactIdproject-b/artifactIdversion1.0.0/versionexclusionsexclusiongroupIdcom.juvenxu.mvnbook/groupIdartifactIdproject-c/artifactId/exclusion/exclusions/dependencydependencygroupIdcom.juvenxu.mvnbook/groupIdartifactIdproject-c/artifactIdversion1.0.0/version/dependency
/dependencies上述代码中当前项目 A 依赖于项目 B但是由于一些原因不想引入传递性依赖 C 而是自己显式地声明对于项目 C 1.1.0 版本的依赖。代码中使用 exclusions 元素声明排除依赖exclusions 可以包含一个或者多个 exclusion 子元素因此可以排除一个或者多个传递性依赖。需要注意的是声明 exclusion 的时候只需要 groupId 和 artifactld而不需要 version 元素这是因为只需要 groupId 和 artifactld 就能唯一定位依赖图中的某个依赖。换句话说Maven 解析后的依赖中不可能出现 groupId 和 artifactld 相同但是 version 不同的两个依赖
归类依赖
简单说就是一批依赖来自同一项目groupId的不同模块artifactId但是版本号相同此时可以不用为每个依赖声明一个 version而是统一定义版本号然后每个依赖引用这个版本号即可。
propertiesmyproject.version1.0.0/myproject.version
/propertiesdependenciesdependencygroupIdcom.juvenxu.mvnbook/groupIdartifactIdproject-b/artifactIdversion${myproject.version}/version/dependencydependencygroupIdcom.juvenxu.mvnbook/groupIdartifactIdproject-c/artifactIdversion${myproject.version}/version/dependency
/dependencies这里简单用到了Maven属性首先使用 properties 元素定义 Maven 属性该例中定义了一个 myproject.version 子元素其值为1.0.0。有了这个属性定义之后Mave n运行的时候会将POM 中的所有的 ${myproject.version} 替换成实际值1.0.0。也就是说可以使用美元符号和大括弧环绕的方式引用 Maven 属性。然后将所有统一依赖的版本值用这一属性引用表示。
优化依赖
在软件开发过程中程序员会通过重构等方式不断地优化自己的代码使其变得更简洁、更灵活。同理程序员也应该能够对 Maven 项目的依赖了然于胸并对其进行优化如去除多余的依赖显式地声明某些必要的依赖。
Maven 会自动解析所有项目的直接依赖和传递性依赖并且根据规则正确判断每个依赖的范围对于一些依赖冲突也能进行调节以确保任何一个构件只有唯一的版本在依赖中存在。在这些工作之后最后得到的那些依赖被称为已解析依赖(Resolved Dependency)。可以运行如下的命令查看当前项目的已解析依赖:
mvn dependency:list在你的项目中执行该命令结果会显示项目的所有的已解析依赖同时每个依赖的范围也得以明确标示。在此基础上还能进一步了解已解析依赖的信息。
将直接在当前项目 POM 声明的依赖定义为顶层依赖而这些顶层依赖的依赖则定义为第二层依赖以此类推有第三、第四层依赖。当这些依赖经 Maven 解析后就会构成一个依赖树通过这棵依赖树就能很清楚地看到某个依赖是通过哪条传递路径引入的。可以运行如下命令查看当前项目的依赖树
mvn dependency:tree通过结果你会发现有的依赖没有声明但是通过别的依赖传递了进来也能看见每个依赖的范围。
使用 dependency:list 和 dependency:tree 可以帮助我们详细了解项目中所有依赖的具体信息在此基础上还有dependency:analyze 工具可以帮助分析当前项目的依赖。
mvn dependency:analyze该结果中重要的是两个部分。首先是 Used umdeclared dependencies意指项目中使用到的但是没有显式声明的依赖这种依赖意味着潜在的风险当前项目可能在使用它们例如有很多相关的 Java import 声明而这种依赖是通过直接依赖传递进来的当升级直接依赖的时候相关传递性依赖的版本也可能发生变化这种变化不易察觉但是有可能导致当前项目出错。例如由于接口的改变当前项目中的相关代码无法编译。这种隐藏的、潜在的威胁一旦出现就往往需要耗费大量的时间来查明真相。因此最好显式声明任何项目中直接用到的依赖。
结果中还有一个重要的部分是 Unused declared dependeneies意指项目中未使用的但显式声明的依赖需要注意的是对于这样一类依赖我们不应该简单地直接删除其声明而是应该仔细分析。由于 dependency:analyze 只会分析编译主代码和测试代码需要用到的依赖一些执行测试和运行时需要的依赖它就发现不了。
