博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
(转)Maven POM中的各种scope的行为总结
阅读量:5245 次
发布时间:2019-06-14

本文共 870 字,大约阅读时间需要 2 分钟。

原地址:https://blog.csdn.net/cnweike/article/details/52221410

compile:默认的scope。任何定义在compile scope下的依赖将会在所有的class paths下可用。maven工程会将其打包到最终的artifact中。如果你构建一个WAR类型的artifact,那么在compile scope下引用的JAR文件将会被集成到WAR文件内。

 

provided:这个scope假定对应的依赖会由运行这个应用的JDK或者容器来提供。最好的例子就是servlet API。任何在provided scope下定义的依赖在构建时的类路径里是可用的,但是不会被打包到最终的artifact中。如果是一个WAR的文件,servlet API在构建时的类路径里是可用的,但是并不会被打包到WAR文件中。

 

runtime:在runtime scope下定义的依赖只会在运行期可用,而在构建期的类路径下不可用。这些依赖将会被打包到最终的artifact中。比如你有一个基于web的应用需要在运行时访问MySQL数据库。你的代码没有任何MySQL数据库驱动的硬依赖。你的代码仅仅是基于JDBC API来编写,在构建期并不需要MySQL数据库驱动。然而,在运行期,就需要相应的驱动来操作MySQL数据库了。因此,这个驱动应该被打包到最终的artifact中。

 

test:只用于测试变异的依赖(比如JUnit),execution必须定义在test scope下。这些依赖不会被打包到最终的artifact中。

 

system:于provided scope很像。唯一的区别在于,在system scope中,你需要告诉Maven如何去找到这个依赖。如果你要引用的依赖在Maven仓库中不存在时,就可以用这个scope。不推荐使用system依赖。

 

import:从其它的pom文件中导入依赖设置。

转载于:https://www.cnblogs.com/MMSJ6/p/9072101.html

你可能感兴趣的文章
android一些细节问题
查看>>
KDESVN中commit时出现containing working copy admin area is missing错误提示
查看>>
利用AOP写2PC框架(二)
查看>>
【动态规划】skiing
查看>>
java定时器的使用(Timer)
查看>>
ef codefirst VS里修改数据表结构后更新到数据库
查看>>
boost 同步定时器
查看>>
[ROS] Chinese MOOC || Chapter-4.4 Action
查看>>
简单的数据库操作
查看>>
解决php -v查看到版本与phpinfo()版本不一致问题
查看>>
iOS-解决iOS8及以上设置applicationIconBadgeNumber报错的问题
查看>>
亡灵序曲-The Dawn
查看>>
Redmine
查看>>
帧的最小长度 CSMA/CD
查看>>
xib文件加载后设置frame无效问题
查看>>
编程算法 - 左旋转字符串 代码(C)
查看>>
IOS解析XML
查看>>
Python3多线程爬取meizitu的图片
查看>>
树状数组及其他特别简单的扩展
查看>>
zookeeper适用场景:分布式锁实现
查看>>