Maven依赖管理

定义maven坐标

每个maven工程都需要定义本工程的坐标，坐标是maven对jar包的身份定义。

<!--项目名称，定义为组织名+项目名，类似包名-->
<groupId>cn.eaglezsx.maven</groupId>
<!--模块名称-->
<artifactId>maven-first</artifactId>
<!--当前项目版本号，snapshot为快照版本即非正式版本，release为正式发布版本-->
<version>0.0.1-SNAPSHOT</version>
<packaging>:打包类型
	jar:执行package会打成jar包
	war：执行package会打成war包
	pom：用于maven工程的继承，通常父工程设置为pom

添加依赖

在pom.xml中添加dependency标签

比如添加对Junit4.9的依赖

<dependencies>
	<!-- 添加junit4.9依赖 -->
  	<dependency>
  		<groupId>junit</groupId>
  		<artifactId>junit</artifactId>
  		<version>4.9</version>
  	</dependency>
</dependencies> 

添加依赖需要指定jar包的坐标，但是很多情况我们是不知道jar包的坐标的，可以通过如下方式查询

1.从互联网搜索

http://search.maven.org/ http://mvnrepository.com/

2.使用maven插件的索引功能。如果在本地仓库有我们要的jar包，可以选择项目，右键，Maven，Add Dependency，在中间的文本框中输入要查找的东西。

手动添加jar包到本地仓库

命令格式

mvn install:install-file -DgroupId=<group_name> -DartifactId=<artifact_name> -Dversion=<version_no> -Dfile=<path_of_the_local_jar> -Dpackaging=jar -DgeneratePom=true

例子

mvn install:install-file -DgroupId=com.qrcode -DartifactId=qrcode -Dversion=1.0 -Dfile=e:/test/QRCode.jar -Dpackaging=jar -DgeneratePom=true

依赖范围

A依赖B，需要在A的pom.xm文件中添加B的坐标，添加坐标时需要指定依赖范围，依赖范围包括：

• compile：编译范围，指A在编译时依赖B，此范围为默认依赖范围。编译范围的依赖会用在编译、测试、运行，由于运行时需要，所以编译范围的依赖会被打包。
• provided：provided依赖只有在当JDK或者一个容器已提供该依赖之后才使用，provided依赖在编译和测试时需要，在运行时不需要，比如：servlet api被tomcat容器提供。
• runtime：runtime依赖在运行和测试系统的时候需要，但在编译的时候不需要。比如：jdbc的驱动包。由于运行时需要，所以runtime范围的依赖会被打包。这种主要是指代码里并没有直接引用而是根据配置在运行时动态加载并实例化的情况。虽然用runtime的地方改成compile也不会出大问题，但是runtime的好处是可以避免在程序里意外地直接引用到原本应该动态加载的包。runtime作用域是为了防止程序员将直接依赖项添加到代码中的实现库，而不是使用抽象或外观，换句话说，它强制使用接口。通过compile和provided引入的jar包，里面的类，你在项目中可以直接import进来用，编译没问题，但是runtime引入的jar包中的类，项目代码里不能直接用，用了无法通过编译，只能通过反射之类的方式来用。
• test：test范围依赖。在编译和运行时都不需要，它们只有在测试编译和测试阶段可用，比如：junit。由于运行时不需要所以test范围依赖不会被打包。
• system：system范围依赖于provided类似，但是你必须显示的提供一个对于本地系统中jar文件的路径，需要指定systemPath磁盘路径，system依赖不推荐使用。

compile（默认范围，可以不写。编译，测试，运行都有效）

servlet-api，jsp-api-----provided(编译，测试有效，运行时无效，防止和tomcat下的jar冲突)

jdbc驱动jar包—runtime（测试，运行有效）

junit----test(测试有效)

依赖范围由强到弱的顺序是：compile>provided>runtime>test

配置plugin修改tomcat的访问路径及端口

  <build>
  	<plugins>
			<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>tomcat-maven-plugin</artifactId>
				<version>1.1</version>
				<configuration>
					<!-- 可以灵活配置工程路径 -->
					<path>/ssh</path>
					<!-- 可以灵活配置端口号 -->
					<port>8080</port>
				</configuration>
			</plugin>
  	</plugins>
  </build>

设置编译版本

设置编译版本，这里需要使用maven的插件来设置，在pom.xml中加入（插件写在build标签的plugins标签里边）

  <build>
  	<plugins>
  		<plugin>
  			<groupId>org.apache.maven.plugins</groupId>
  			<artifactId>maven-compiler-plugin</artifactId>
  			<configuration>
  				<source>1.7</source>
  				<target>1.7</target>
  				<encoding>UTF-8</encoding>
  			</configuration>
  		</plugin>
  	</plugins>
  </build>

设置完编译版本之后，会报红叉，因为系统不知道，需要通知他一下，项目右击–>Maven–>Update Project Configuration，红叉即消失，并且会发现JRE System Library变成1.7。

依赖传递

弄ssh的时候，会发现只添加一个struts2-core的依赖，所有关于struts2的依赖都进来了。

因为项目依赖struts2-core-2.3.24.jar，而struts2-core-2.3.24.jar会依赖xwork-core-2.3.24.jar等等，所以xwork-core-2.3.24.jar这些jar包也出现在了maven工程中，这种现象称为依赖传递。

在eclipse中，打开pom.xml，选中下边的Dependency Hierarchy，就可以看到依赖的层级关系了。
例如：

• A->B：A依赖B，第一直接依赖
• B->C：B依赖C，第二直接依赖
• A->C：A依赖C，间接依赖，间接依赖的依赖范围受到第一直接依赖和第二直接依赖的影响，具体影响，见表格。

列是第一直接依赖，行是第二直接依赖，“-”代表无依赖。

依赖冲突的解决

我添加了struts2-spring-plugin和spring-context这两个依赖，会发现这两个jar包都同时依赖了spring-beans，

struts2-spring-plugin依赖了spring-beans-3.0.5，spring-context依赖spring-beans-4.2.4,但是发现spring-beans-3.0.5加入到工程中，而我们希望spring-beans-4.2.4加入工程。这就造成了依赖冲突。

解决依赖冲突有以下原则（依赖调解原则）：

maven自动按照下边的原则调解：

1.第一声明者优先原则。在pom文件定义依赖，先声明的依赖为准。如果将上边struts2-spring-plugin和spring-context顺序颠倒，系统将导入spring-beans-4.2.4。因为spring-context在前边，所以以spring-context依赖的spring-beans-4.2.4为准，所以最终spring-beans-4.2.4添加到了工程中。

2.路径近者优先原则。例如：A依赖spring-beans-4.2.4；A依赖B，B依赖spring-beans-3.0.5；则spring-beans-4.2.4优先被依赖在A中，因为spring-beans-4.2.4相对spring-beans-3.0.5被A依赖的路径最近。

如果在ssh的工程中的pom中加入spring-beans-4.2.4的依赖，根据路径优先原则，系统将自动导入spring-beans-4.2.4。

排除依赖

上边的问题可以通过排除依赖方法辅助依赖调解，比如在依赖struts2-spring-plugin的设置中添加排除依赖，排除spring-beans.

		<!-- struts2-spring-plugin依赖spring-beans-3.0.5 -->
		<dependency>
			<groupId>org.apache.struts</groupId>
			<artifactId>struts2-spring-plugin</artifactId>
			<version>2.3.24</version>
			<!-- 排除spring-beans -->
			<exclusions>
				<exclusion>
					<groupId>org.springframework</groupId>
					<artifactId>spring-beans</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

锁定版本

面对众多的依赖，有一种方法不用考虑依赖路径、声明优化等因素可以采用直接锁定版本的方法确定依赖构建的版本，版本锁定后则考虑依赖的声明顺序或依赖的路径，以锁定的版本为准添加到工程中，此方法在企业开发中常用。

如下配置是锁定了spring-beans和spring-context的版本：

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.springframework</groupId>
				<artifactId>spring-beans</artifactId>
				<version>4.2.4.RELEASE</version>
			</dependency>
			
			<dependency>
				<groupId>org.springframework</groupId>
				<artifactId>spring-context</artifactId>
				<version>4.2.4.RELEASE</version>
			</dependency>
		</dependencies>
	</dependencyManagement>

注意：在工程中锁定依赖的版本并不代表在工程中添加了依赖，如果工程需要添加锁定版本的依赖则需要单独添加<dependencies></dependencies>标签

	<dependencies>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-beans</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-context</artifactId>
		</dependency>
	</dependencies>

上边添加的依赖并没有指定版本，原因是已在<dependencyManagement>中锁定了版本，所以在<dependency>下不需要再指定版本。

还可以把版本号提出去，方便以后修改

	<!-- 属性 -->
	<properties>
		<spring.version>4.2.4.RELEASE</spring.version>
	</properties>

	<!-- 锁定版本 -->
	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.springframework</groupId>
				<artifactId>spring-beans</artifactId>
				<version>${spring.version}</version>
			</dependency>
		</dependencies>
	</dependencyManagement>
	
	<!-- 依赖管理 -->
	<dependencies>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-beans</artifactId>
		</dependency>
	</dependencies>