Maven-Dependency Mechanism

依赖管理是maven的一个广为人知的特性, 这也是maven擅长的一个领域. 为单一的工程管理依赖不是很难, 但当你着手处理多模块工程和包含数十或数百个模块的应用时, maven可以帮助你很好地保持高度控制和稳定性.

Transitive Dependencies

依赖传递性是 maven 2.0中的一个新特性. 这不需要你去搜索和指定你自己的依赖需要的库, 而是自动地包含它们.

这个特性通过从指定的远程仓库读取你依赖的工程文件. 通常, 那些工程的所有依赖关系都会用于你的工程, 因为该项目从其父母或依赖关系中继承了这些.

没有限制依赖的组织层次数目, 但如果发现一个循环依赖就会发生问题.

由于依赖传递, 包含库的关系图会迅速变得很大. 因此, 有一些额外的特性来限制哪些依赖被包含:

(1) Dependency mediation. 依赖调解. 这决定了, 当一个构件的多个版本相遇时, 使用哪个版本的依赖. 目前, maven 2.0 只支持使用最近的定义("nearest definition"), 就是说, 它将使用在依赖树中离你的项目最近的版本. 你可以显式地在项目的pom文件中声明, 保证总是使用某个特定的版本. 注意, 如果2个依赖版本在依赖树中的深度一样, 在maven 2.0.8之前, 它没有定义哪个版本会胜出, 但从maven 2.0.9, 由声明的顺序来决定, 第一声明者优先.

nearest definition, 是指在依赖树中离你的工程最近的那个版本. 比如, 如果A,B,C之间的依赖关系为: A->B->C->D 2.0, 以及 A->E->D 1.0, 这样, 当构建A时, 将会使用 D 1.0. 因为从A到D的路径, 后者更短.  你可以显式地在A中添加一个依赖 D 2.0, 强制使用D 2.0.

(2) Dependency management. 依赖管理. 当构件在依赖传递中 或没有指定版本的依赖中相遇时, 工程作者可以直接 指定使用构件的哪个版本. 在上一节的例子中, 一个依赖会被添加到A中, 即使它不是直接被A使用. 相反, A可以在它的依赖管理中包含D作为一个依赖, 直接控制D在被引用时使用哪个版本.

(3) Dependency scope. 依赖范围. 只包含适合当前构建阶段的依赖. 下面会详细描述这一点.

(4) Excluded dependencies. 排除依赖. 如果工程X依赖工程Y, 工程Y依赖工程Z, 工程X的所有者可以显式地排除工程Z作为一个依赖, 使用 exclusion 元素 .

(5) Optional dependencies. 可选依赖. 如果工程Y依赖工程Z, 工程Y的所有者可以标记工程Z作为一个可选依赖, 使用optional标签. 当工程X依赖工程Y时, X将只依赖Y, 而不依赖Z. X的所有者也可显式地添加Z作为一个依赖. 这有助于将可选依赖理解为默认的排除依赖.

Dependency Scope

Reference

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies

时间: 2024-10-27 18:15:21

Maven-Dependency Mechanism的相关文章

使用Eclipse的Maven插件时maven dependency找不到包的解决办法

引入maven项目,提示找不到maven dependency包时候: 解决方法如下: 1.eclipse菜单 window-> show view –> other –> Maven 2.在打开的窗口里,右键 local repositories –> local repository ,右击选择 rebuild index,耐心的等待重新下载.

Maven--->学习心得--->maven的Dependency Mechanism(依赖关系机制)

1.概述: dependency management是maven所擅长的东西之一,是maven的特色功能. 参考资料:1)maven官网documentation 2) 2.maven的依赖机制 1)maven中的依赖是可传递的(transitive denpendencies) pom.xml可以继承parent pom.xml 可以自动继承该项目所依赖的三方工程(dependencies)依赖的其他工程 由于maven管理的项目,其依赖是可传递的,所以就容易出现一个问题,那就是依赖有可能形

<Maven><Dependency><Conflict>

maven conflict solution: scenerio: Runtime Error: ``` java.lang.SecurityException: class "javax.servlet.FilterRegistration"'s signer information does not match signer information of other classes in the same package ``` google, and know this is

Maven Dependency Scope用法

原帖地址:http://uule.iteye.com/blog/2087485 官方API描述 Dependency scope 是用来限制Dependency的作用范围的, 影响maven项目在各个生命周期时导入的package的状态. 自从2.0.9后,新增了1种,现在有了6种scope: compile默认的scope,表示 dependency 都可以在生命周期中使用.而且,这些dependencies 会传递到依赖的项目中. provided跟compile相似,但是表明了depend

maven dependency的版本冲突问题

在改造一个旧项目中,遇到各种问题. 旧项目有十多个模块,因为没有一个统一的父pom,它们对第三方的jar的版本没有统一. 虽然也存在公共的依赖模块,比如commons.util,但是,我们的模块中,有时候又会自己重复引用一些基础的.已经在公共依赖模块存在的对三方jar, 这样 就造成了很多的冲突. 当我考虑统一到一个父pom里面去的时候,发现了很多问题. [ERROR] [ERROR] The project com.wisdom:mint:1.0-SNAPSHOT (F:\dev\SVN\co

Maven Dependency错误——下载失败问题解决方案

问题描述: The container 'Maven Dependencies' references non existing library '${groupid}/${artifactid}-${version}.jar' 解决方案: 上面问题往往是在下载依赖过程中网络出现问题导致的.此时我们本机已经开始下载依赖代码,但是下载失败,本机仓库中会在${MAVEN_repo}/${groupid}/${artifactid}/${version} 路径下面生成 *.lastUpdated 的文

spring security maven dependency

Unable to locate Spring NamespaceHandler for XML schema namespace [ spring secutity dependency: <!-- Spring Security --> <dependency> <groupId>org.springframework.security</groupId> <artifactId>spring-security-core</artifa

[转]json-lib 的maven dependency

转载自http://www.cnblogs.com/yqskj/archive/2013/05/27/3101934.html 项目中要用到json-lib,mvnrepository.com查找它的dependency时结果如下: xml 代码 <dependency> <groupId>net.sf.json-lib</groupId> <artifactId>json-lib</artifactId> <version>2.4&

intellij idea maven dependency自动补全

最近在idea上使用maven插件,在pom.xml编写项目依赖的jar包时,已经下载到本地的jar,无法自动补全,需要手动写出来.非常影响效率. 对于这个问题,可以在maven的setting中手动更新本地仓库的jar索引来解决.如下 File --> setting-->maven-->Repositories,选中本地的仓库,点击右上角的update,更新maven仓库索引. 这样对于已经下载到本地的jar都可以自动进行补全了.

Maven的依赖机制介绍

以下内容引用自https://ayayui.gitbooks.io/tutorialspoint-maven/content/book/maven_manage_dependencies.html: 一.前言 Maven的一个核心特性就是依赖管理.当我们涉及到多模块的项目(包含成百个模块或者子项目),管理依赖就变成一项困难的任务.Maven展示出了它对处理这种情形的高度控制. 二.可传递性依赖 一种相当常见的情况,当一个库,比如说A依赖于其他库B.假如,另外一个项目C想要使用A,那么项目也需要使