maven 父子级别工程 结构错误

文章目录

• 1、 基本概念
• 2、 直接依赖和间接依赖
• 3、 依赖的范围（重点）
• 4、 依赖的传递性
• 5、 依赖的原则：解决jar包冲突
• 6、 依赖的排除
• 7、 统一管理目标jar包的版本

查找依赖的网址：

http://mvnrepository.com

1、 基本概念

当A jar包需要用到B jar包中的类时，我们就说A对B有依赖。

例如：commons-fileupload-1.3.jar依赖于commons-io-2.0.1.jar。

2、 直接依赖和间接依赖

如果A依赖B，B依赖C，那么A→B和B→C都是直接依赖，而A→C是间接依赖。

3、 依赖的范围（重点）

当一个Maven工程添加了对某个jar包的依赖后，这个被依赖的jar包可以对应下面几个可选的范围：

①compile

[1] main目录下的Java代码可以访问这个范围的依赖

[2] test目录下的Java代码可以访问这个范围的依赖

[3] 部署到Tomcat服务器上运行时要放在WEB-INF的lib目录下

例如：对Hello的依赖。主程序、测试程序和服务器运行时都需要用到。

②test

[1] main目录下的Java代码不能访问这个范围的依赖

[2] test目录下的Java代码可以访问这个范围的依赖

[3 部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下

例如：对junit的依赖。仅仅是测试程序部分需要。

③provided

[1] main目录下的Java代码可以访问这个范围的依赖

[2] test目录下的Java代码可以访问这个范围的依赖

[3] 部署到Tomcat服务器上运行时不会放在WEB-INF的lib目录下

例如：servlet-api在服务器上运行时，Servlet容器会提供相关API，所以部署的时候不需要。

④runtime[了解]

[1] main目录下的Java代码不能访问这个范围的依赖

[2] test目录下的Java代码可以访问这个范围的依赖

[3] 部署到Tomcat服务器上运行时会放在WEB-INF的lib目录下

例如：JDBC驱动。只有在测试运行和在服务器运行的时候才决定使用什么样的数据库连接。

⑤其他：import、system等。

各个依赖范围的作用可以概括为下图：

4、 依赖的传递性

当存在间接依赖的情况时，主工程对间接依赖的jar可以访问吗？

这要看间接依赖的jar包引入时的依赖范围——只有依赖范围为compile时可以访问。

例如：

Maven工程	依赖范围	对A的可见性
A	B	C	compile	√
D	test	×
E	provided	×

5、 依赖的原则：解决jar包冲突

①路径最短者优先

②路径相同时先声明者优先

这里“声明”的先后顺序指的是dependency标签配置的先后顺序。

6、 依赖的排除

有的时候为了确保程序正确可以将有可能重复的间接依赖排除。排除掉后也可以自行依赖其他版本。

<dependency>
	<groupId>com.atguigu.maven</groupId>
	<artifactId>Survey160225_4_Environment</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<!-- 依赖排除 -->
	<exclusions>
		<exclusion>
			<groupId>commons-logging</groupId>
			<artifactId>commons-logging</artifactId>
		</exclusion>
	</exclusions>
</dependency>
<dependency>
	<groupId>commons-logging</groupId>
	<artifactId>commons-logging</artifactId>
	<version>1.1.2</version>
</dependency>

7、 统一管理目标jar包的版本

以对Spring的jar包依赖为例：Spring的每一个版本中都包含spring-core、spring-context等jar包。我们应该导入版本一致的Spring jar包，而不是使用4.0.0的spring-core的同时使用4.1.1的spring-context。

<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-core</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-context</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-jdbc</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-orm</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-web</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-webmvc</artifactId>
	<version>4.0.0.RELEASE</version>
</dependency>

问题是如果我们想要将这些jar包的版本统一升级为4.1.1，是不是要手动一个个修改呢？显然，我们有统一配置的方式：

<properties>
	<spring.version>4.1.1.RELEASE</spring.version>
</properties>

<!-- 。。。。。。。 -->


		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-core</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-context</artifactId>
		<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-jdbc</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-orm</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-web</artifactId>
			<version>${spring.version}</version>
		</dependency>
		<dependency>
			<groupId>org.springframework</groupId>
			<artifactId>spring-webmvc</artifactId>
			<version>${spring.version}</version>
		</dependency>

这样一来，进行版本调整的时候只改一改地方就行了。