Maven小白--Maven依赖传递（七）

最新推荐文章于 2024-08-02 17:47:47 发布

原创最新推荐文章于 2024-08-02 17:47:47 发布 · 795 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

Maven 专栏收录该内容

14 篇文章

订阅专栏

本文深入解析Maven内置变量的使用，详细说明了依赖管理的scope作用范围及其影响，探讨了依赖传递规则，并介绍了如何通过<exclusion>进行依赖排除。适合Maven初学者及希望深化理解Maven配置的开发者。

一、Maven内置隐式变量

${basedir} 项目根目录
${project.build.directory} 构建目录，缺省为target
${project.build.outputDirectory} 构建过程输出目录，缺省为target/classes
${project.build.finalName} 产出物名称，缺省为${project.artifactId}-${project.version}
${project.packaging} 打包类型，缺省为jar
${project.xxx} 当前pom文件的任意节点的内容

参考链接 Maven内置隐式变量

示例：
<dependency>
   <groupId>${project.groupId}</groupId>
   <artifactId>user-log</artifactId>
   <version>${project.version}</version>
   </dependency>

二、Maven依赖

scope 是用来限制 dependency 依赖的作用范围的，影响 maven 项目在各个生命周期时导入的 package 的状态，主要管理依赖的部署。

scope 的作用范围：

（1）compile：默认值，适用于所有阶段（表明该 jar 包在编译、测试以及运行三个范围中都有效），并且会随着项目一起发布。编译的时候加入依赖。打包的时候也加入依赖。

（2）test：只在测试时使用，用于编译和运行测试代码，不会随项目发布。

（3）runtime：无需参与项目的编译，不过后期的测试和运行周期需要其参与，与 compile 相比，跳过了编译。如 JDBC 驱动，适用运行和测试阶段。

（4）provided：编译和测试时有效，但是该依赖在运行时由服务器提供，所以打包时不应该被包含进去，否则会jar包冲突。如 servlet-api。编译的时候加入依赖。打包的时候不加入依赖。

（5）system：类似 provided，需要显式提供包含依赖的jar，不会从 maven 仓库下载，而是从本地文件系统获取，需要添加 systemPath 的属性来定义路径。

三、依赖传递

scope的值为test时，依赖不会被传递。
直接依赖&间接依赖，当出现间接依赖时，首先出现的包会被依赖

项目A依赖于包jar1.0，项目B依赖于包jar2.0，项目C依赖于项目A和B，那么项目C到底是依赖于哪个版本呢？

答案：如果包jar1.0与包jar2.0是同一级别的依赖，依赖于先出现的版本。比如先引入依赖A，则项目C依赖于jar1.0，项目C和jar1.0的关系是间接依赖。

同一级别的依赖，首先出现的包会被依赖；依赖级别不同，依赖于第一级依赖。

四、依赖排除<exclusion>...</exclusion>

<dependency>
	<groupId>${project.groupId}</groupId>
	<artifactId>user-log</artifactId>
	<version>${project.version}</version>
	<!-- 依赖排除 -->
	<exclusions>
		<exclusion>
			<groupId>commons-logging</groupId>
			<artifactId>commons-logging</artifactId>
		</exclusion>
	</exclusions>
</dependency>