本文共 5706 字，大约阅读时间需要 19 分钟。
目录
一、依赖机制
1、基本的依赖配置格式：
org.apache.maven maven-artifact 3.8.1 compile
其中version标签如果不配置，则Maven自动寻找最新的版本。
2、在Maven仓库中定位下载的依赖jar:
将groupId+artifactId+version按照格式连接起来：
com/starfall/maven/Maven/0.0.1-SNAPSHOT/Maven-0.0.1-SNAPSHOT.jar
3、全量的dependencies标签参考：
org.apache.maven maven-artifact 3.8.1 jar test spring-core org.springframework true
二、依赖范围
项目的主程序和测试程序不同阶段的有效性：
注意点：
- 编译依赖范围（compile）。该范围就是默认依赖范围，此依赖范围对 于编译、测试、运行三种都有效。
- 测试依赖范围(test)。最典型的例子就是 Junit, 构件在测试时才需要，所以它的依赖范围是测试，因此它的依赖范围需要显示指定为<scope>test</scope> ,当然不显示指定依赖范围也不会报错，但是该依赖会被加入到编译和运行的classpath中,造成不必要的浪费 。
- 已提供依赖范围(provided)。官方举了一个例子。比如在JavaEE web项目中我们需要使用servlet的API，但是呢Tomcat中已经提供这个jar，我们在编译和测试的时候需要使用这个api，但是部署到tomcat的时候，如果还加入servlet构建就会产生冲突，这个时候就可以使用provided。
- 运行时依赖范围(runtime)。典型例子就是JDBC的驱动实现，项目主代码编译的时候只需要提供的JDBC接口，只有在测试和运行的时候才需要实现上述接口的具体JDBC驱动。
三、可传递性依赖
1、依赖的传递性
B依赖于其他库C。如果，另外一个项目 A想要使用 B ，那么A 项目也需要使用库C。
但是 A依赖B、B依赖C、那么A能不能使用C，需要查看B依赖C的范围是不是compile：
此时，Maven 提供一些功能来控制可传递的依赖的程度。
| 功能 | 功能描述 |
|---|---|
| 依赖调节 | 决定当多个手动创建的版本同时出现时，哪个依赖版本将会被使用。 如果两个依赖版本在依赖树里的深度是一样的时候，第一个被声明的依赖将会被使用。 |
| 依赖管理 | 直接的指定手动创建的某个版本被使用。例如当一个工程 C 在自己的依赖管理模块包含工程 B，即 B 依赖于 A， 那么 A 即可指定在 B 被引用时所使用的版本。 |
| 依赖范围 | 包含在构建过程每个阶段的依赖。 |
| 依赖排除 | 任何可传递的依赖都可以通过 "exclusion" 元素被排除在外。举例说明，A 依赖 B， B 依赖 C，因此 A 可以标记 C 为 "被排除的"。 |
| 依赖可选 | 任何可传递的依赖可以被标记为可选的，通过使用 "optional" 元素。例如：A 依赖 B， B 依赖 C。因此，B 可以标记 C 为可选的， 这样 A 就可以不再使用 C。 |
2、依赖排除
例如在引入依赖Spring-core的jar时候，会同步的引入commons-logging的jar，说明Spring的jar依赖于commons-logging。
但是如果此时想要从依赖中排除掉commons-logging的jar时候，需要如下做法：
排除配置：
org.springframework spring-core 4.0.0.RELEASE commons-logging commons-logging
3、依赖的原则
（3.1）路径最短
A项目依赖B、B项目依赖C。此时B、C中都有不同版本的log4j的依赖，在A项目中根据路径最短原则Maven会引用B声明的log4j版本。
（3.2）路径相同时，先声明者优先。
A项目依赖B和C，B、C中有两个版本的log4j依赖，则A中使用先声明的那个项目的依赖。
四、引入外部依赖
1、systemPath
如果存在自己打包的jar，不会存在Maven本地仓库、中央仓库及其远程仓库。只能在 src 文件夹下添加 lib 文件夹，然后将jar复制到该目录下。例如：
那么 Maven 构建将会失败，因为它在编译阶段使用指这个库无法下载或无法找到。
此时需要添加外部依赖项：
ldapjdk ldapjdk 1.0 system ${basedir}\src\lib\ldapjdk.jar
- 指定 groupId 同样作为库的名称；
- 指定 artifactId 同样作为库的名称；
- 指定范围的系统；
- 指定相系统项目的位置；
2、定制库到Maven本地资源库
1中是把jar复制在项目中，另一种方法是将jar安装到Maven本地仓库中，这样可以使用正常的依赖引入此jar
示例：kaptcha，它是一个流行的第三方Java库，它被用来生成 “验证码” 的图片，以阻止垃圾邮件，但它不在 Maven 的中央仓库中。
安装 “kaptcha” jar 到Maven 的本地资源库，参考：
2.1、先准备好jar包，命名版本，并放在一个目录下：c:\kaptcha-2.3.jar
执行命令：
mvn install:install-file -Dfile=c:\kaptcha-{version}.jar -DgroupId=com.google.code -DartifactId=kaptcha -Dversion={version} -Dpackaging=jar 执行结果：
D:\>mvn install:install-file -Dfile=c:\kaptcha-2.3.jar -DgroupId=com.google.code -DartifactId=kaptcha -Dversion=2.3 -Dpackaging=jar[INFO] Scanning for projects...[INFO] Searching repository for plugin with prefix: 'install'.[INFO] ------------------------------------------------------------------------[INFO] Building Maven Default Project[INFO] task-segment: [install:install-file] (aggregator-style)[INFO] ------------------------------------------------------------------------[INFO] [install:install-file][INFO] Installing c:\kaptcha-2.3.jar to D:\maven_repo\com\google\code\kaptcha\2.3\kaptcha-2.3.jar[INFO] ------------------------------------------------------------------------[INFO] BUILD SUCCESSFUL[INFO] ------------------------------------------------------------------------[INFO] Total time: < 1 second[INFO] Finished at: Tue May 12 13:41:42 SGT 2014[INFO] Final Memory: 3M/6M[INFO] ------------------------------------------------------------------------
出现上述画面kaptcha-2.3.jar被复制到Maven本地仓库。
2.2、在pom中引用该jar:
com.google.code kaptcha 2.3
五、统一管理依赖的版本
1、使用<properties>标签统一依赖版本：
4.0.0 com.starfall.ssm SSM 0.0.1-SNAPSHOT war 4.3.18.RELEASE 1.8.0 3.4.6 org.springframework spring-core ${spring.version} org.springframework spring-context ${spring.version} org.springframework spring-jdbc ${spring.version} org.springframework spring-test ${spring.version} org.aspectj aspectjrt ${aop.version} org.aspectj aspectjweaver ${aop.version} org.springframework spring-webmvc ${spring.version} org.mybatis mybatis ${mybatis.version}
2、设置项目编码
转载地址：http://mplci.baihongyu.com/