前言
Maven 的哲学思想是,约定优于配置(Convention Over Configuration),Maven 依赖中 scope 的默认值是compile
Scope 指定了依赖(第三方jar包)的 作用范围
作用范围包括,所在项目的测试、编译、运行、打包等生命周期
其中,编译和运行还分为
测试代码的编译和运行
非测试代码的编译和运行
scope 分类
test 测试范围
测试范围的依赖(第三方jar包),针对测试相关代码的编译和运行,在通常代码的编译和运行时都不需要,只有在有关测试的代码编译和运行测试代码阶段可用
案例说明
环境 IJ maven web project
前提:需知facade slf4j 只有在classpath 中发现底层日志实现framework时才起作用
pom.xml
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <!--此处test,表明 junit jar包只能出现在 test 环境下的classpath, 即 只能在标记为 “TestSources Root的 文件夹下”被调用, 而在“标记为Sources Root 的文件夹下”找不到其中的类--> <scope>test</scope> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.7.25</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>1.7.25</version> <!--此处test 是关键,表明底层日志实现框架-也即该依赖在test 代码编译、运行时才起作用--> <scope>test</scope> </dependency> </dependencies> |
测试代码
测试方法之一,即是上面pom注释,junit 类调用只能在TestSources Root 目录下起作用
测试方法之二
Sources Root 目录下
1 2 3 4 5 6 7 8 9 10 11 12 13 | public class LogDemo { Logger logger = LoggerFactory.getLogger(LogDemoTest.class); public static void main(String[] args) { Logger logger = LoggerFactory.getLogger(LogDemo.class); //不能找到底层日志使系统,因为 该依赖 为 test 范围 logger.info("log"); } } 输出: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. |
TestSources Root 目录下
1 2 3 4 5 6 7 8 9 10 11 | public class LogDemoTest { Logger logger = LoggerFactory.getLogger(LogDemoTest.class); @Test public void test() { //能找到底层日志实现系统 logger.info("junit test"); } } 输出: [main] INFO log.learn.LogDemoTest - junit test |
compile 编译范围
依赖默认范围,该依赖需要参与当前项目的编译、测试、运行、打包
什么叫参与当前项目的编译???
runtime 运行时范围
表示依赖无需参与当前项目的编译,但是后期的运行和测试需要参与,不参与编译能运行成功吗??
与 compile 相比,跳过编译而已
比如,你可能在编译的时候需要 JDBC API JAR,只有在 运行时才需要 JDBC
貌似是编译时该包不参与,运行时参与?
provided 表明该依赖已经提供,故只在未提供时才被使用
应用场景是你定义了一个Servlet,此刻得需要Servlet-api.jar 才能编译成功,但是当你达成war 包时,你并不想将 Servlet-api.jar 包进去,因为Tomcat等容器会提供
跟compile 类似,说明JDK、容器或使用者会提供这个依赖,如Servlet.jar
这个依赖只作用在** 编译和测试,该依赖会由系统组件提供,不需手动添加,只存在编译、运行、测试阶段,打包是不用包进去,打包阶段做了exclude**动作
没有传递性
system
被依赖项不会从maven仓库下载,而是从本地系统指定路径下寻找,需要 systemPath 属性
scope 的传递依赖
A -> B -> C, 当前项目 A,A依赖于B,B依赖于C,知道B在 A中的scope,怎么知道 C在 A 中的 scope
即,A需不需要 C的问题,本质由 C在B中的scope决定
当 C 在 B 中的scope 是test 或 provided 时,C 直接被丢弃,A不依赖C
否则 A 依赖 C,C的scope 继承与B 的scope