maven基础和常见的问题
参考网址:
https://mp.weixin.qq.com/s/YfI-cGpKzB1l5Xfjs34z3w
1.仓库之间的关系
Maven仓库:
本地仓库路径配置
D:\mavenres3.6
项目寻找依赖的流程
你要jar包,不可能每次都要联网去下载吧,多费劲,所以本地仓库就是相当于加了一层jar包缓存,先到这里来查。如果这里查不到,那么就去私服上找,如果私服也找不到,那么去中央仓库去找,找到jar后,会把jar的信息同步到私服和本地仓库中。
2.依赖管理
其实这个标签揭示了jar的查找坐标:**groupId** 、**artifactId** 、**version** 。
version分为开发版本(Snapshot)和发布版本(Release),那么为什么要分呢?
在实际开发中,我们经常遇到这样的场景,比如A服务依赖于B服务,A和B同时开发,B在开发中发现了BUG,修改后,将版本由1.0升级为2.0,那么A必须也跟着在POM.XML中进行版本升级。过了几天后,B又发现了问题,进行修改后升级版本发布,然后通知A进行升级…可以说这是开发过程中的版本不稳定导致了这样的问题。
Maven,已经替我们想好了解决方案,就是使用Snapshot版本,在开发过程中B发布的版本标志为Snapshot版本,A进行依赖的时候选择Snapshot版本,那么每次B发布的话,会在私服仓库中,形成带有时间戳的Snapshot版本,而A构建的时候会自动下载B最新时间戳的Snapshot版本!
3.处理依赖冲突
比如工程中需要引入A、B,而A依赖1.0版本的C,B依赖2.0版本的C,那么问题来了,C使用的版本将由引入A、B的顺序而定?这显然不靠谱!如果A的依赖写在B的依赖后面,将意味着最后引入的是1.0版本的C,很可能在运行阶段出现类(ClassNotFoundException )、方法(NoSuchMethodError )找不到的错误(因为B使用的是高版本的C)!
什么是依赖传递
***依赖传递:如果A依赖B,B依赖C,那么引入A,意味着B和C都会被引入。
***
4.引入依赖的最佳实践,提前发现问题
在工程中,我们避免不了需要加一些依赖,也许加了依赖后运行时才发现存在依赖冲突在去解决,似乎有点晚!那么能不能提前发现问题呢?
如果我们新加入一个依赖的话,那么先通过mvn dependency:tree
命令形成依赖树,看看我们新加入的依赖,是否存在传递依赖,传递依赖中是否和依赖树中的版本存在冲突,如果存在多个版本冲突,利用上文的方式进行解决!
5. Maven规范化目录结构
这里需要注意2点:
第一:src/main下内容最终会打包到Jar/War中,而src/test下是测试内容,并不会打包进去。
第二:src/main/resources中的资源文件会COPY至目标目录,这是Maven的默认生命周期中的一个规定动作。(想一想,hibernate/mybatis的映射XML需要放入resources下,而不能在放在其他地方了)
6.maven的声明周期
Maven生命周期:
我们只需要注意一点:执行后面的命令时,前面的命令自动得到执行。
实际上,我们最常用的就是这么几个:
clean:有问题,多清理!
package:打成Jar or War包,会自动进行clean+compile
install:将本地工程Jar上传到本地仓库
deploy:上传到私服
7、关于scope依赖范围
compile:默认的scope,运行期有效,需要打入包中。
provided:编译期有效,运行期不需要提供,不会打入包中。
runtime:编译不需要,在运行期有效,需要导入包中。(接口与实现分离)
test:测试需要,不会打入包中
。
会打入包中。`**
runtime:编译不需要,在运行期有效,需要导入包中。(接口与实现分离)
test:测试需要,不会打入包中
。
system:非本地仓库引入、存在系统的某个路径下的jar。(一般不使用)