一、基本区别描述
1.1 compile
默认的scope。任何定义在compile scope下的依赖将会在所有的class paths下可用。
maven工程会将其打包到最终的artifact中。如果你构建一个WAR类型的artifact,
那么在compile scope下引用的JAR文件将'会被集成到WAR文件内'。
1.2 provided
这个scope假定对应的依赖会由运行这个应用的JDK或者容器来提供。
最好的例子就是servlet API。任何在provided scope下定义的依赖在构建时的类路径里是可用的,但是'不会被打包到最终的artifact中'。
如果是一个WAR的文件,servlet API在构建时的类路径里是可用的,但是并不会被打包到WAR文件中。
– 补充provided和compile的主要区别
`重点:`
'这个项目打成war包时,scope=provided的jar包,不会出现在WEB-INFO/lib目录下'
'而scope=compile的jar包,会放到WEB-INFO/lib目录'
1.3 runtime
在runtime scope下定义的依赖'只会在运行期可用',而在构建期的类路径下不可用。
这些依赖将'会被打包到最终的artifact中'。比如你有一个基于web的应用需要在运行时访问MySQL数据库。
你的代码没有任何MySQL数据库驱动的硬依赖。你的代码仅仅是基于JDBC API来编写,在构建期并不需要MySQL数据库驱动。
然而,在运行期,就需要相应的驱动来操作MySQL数据库了。因此,这个驱动应该被打包到最终的artifact中。
1.4 test
'只用于测试变异的依赖'(比如JUnit),execution必须定义在test scope下。这些依赖不会被打包到最终的artifact中。
1.5 system
于provided scope很像。唯一的区别在于,在system scope中,你需要告诉Maven如何去找到这个依赖。
'如果你要引用的依赖在Maven仓库中不存在时,就可以用这个scope'。不推荐使用system依赖。
跟provided 相似,但是在系统中要以外部JAR包的形式提供,maven不会在repository查找它。
– 补充不推荐使用该scope的原因
系统范围,与provided类似,只是标记为该scope的依赖包需要明确指定基于文件系统的jar包路径。
'因为需要通过systemPath指定本地jar文件路径,所以该scope是不推荐的'。如下:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
<scope>system</scope>
<systemPath>${project.basedir}/libs/test.jar</systemPath>
</dependency>
'同时打包时候对应的build需要添加相关参数才能打包进去',如下:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<includeSystemScope>true</includeSystemScope>
</configuration>
</plugin>
</plugins>
<finalName>${artifactId}</finalName>
</build>
所以这种方式不推荐
1.6 import
从其它的pom文件中导入其所有依赖设置
'import scope只能用在dependencyManagement里面'
– 补充使用import scope解决maven继承(单)问题
'博友一描述:'
我们知道Maven的继承和Java的继承一样,是无法实现多重继承的,如果10个、20个甚至更多模块继承自同一个模块,
那么按照我们之前的做法,这个父模块的dependencyManagement会包含大量的依赖。如果你想把这些依赖分类以更清晰的管理,
那就不可能了,import scope依赖能解决这个问题。你可以把dependencyManagement放到单独的专门用来管理依赖的pom中,
然后在需要使用依赖的模块中通过import scope依赖,就可以引入dependencyManagement。
– 自我总结和注意事项
'自我总结'
上面说这么多其本质上我可以理解成使用该scope可以直接复制其对应的所有依赖不必一一引用。例如在dependencyManagement中:spring-boot-dependencies 的以来引用如下:
<!-- spring-boot -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
spring-boot-dependencies依赖中就包含了大量的依赖如:日志三依赖组件logback-classic、logback-access、logback-core,spring-boot等等等等。仅需要用这样(相当于全量复制了),需要使用其中具体组件时自己再具体引用。(个人理解)
'注意事项'
由于如上述所说属于全量复制,里面存在大量依赖 因此依赖冲突问题是需要去注意的。
`如果需要覆盖其中依赖,则需要将覆盖的依赖放在对应scope引用的依赖前`
'如下案例:'
<dependencyManagement>
<dependencies>
<!-- logback日志三组件 注意此处放在最前面用于覆盖spring-boot-dependencies中的日志依赖 -->
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-access</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>${log4j-over-slf4j.version}</version>
</dependency>
<!-- spring-boot -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
<dependencyManagement>
参考文章:
maven dependency中provided和compile的区别