maven基础和常见的问题

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。（一般不使用）