maven相关学习

1、入门

• 打包maven命令

mvn -compile:编译,生成target
mvn -clean:清理,删除target
mvn -test:测试
mvn -package:编译并且打包
mvn -install:发布到本地(远程)仓库

• maven 依赖

pom:依赖与继承
war：web工程
jar：java项目

• 搭建多模块工程

parent模块: pom类型
jar类型：可继承pom
springboot内置tomcat直接打jar包
解决依赖冲突：<exclusion>

• Maven的生命周期

clean：有问题，多清理！
package：打成Jar or War包，会自动进行clean+compile
install：将本地工程Jar上传到本地仓库
deploy：上传到私服

2、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、依赖冲突

对于Maven而言，同一个groupId同一个artifactId下，只能使用一个version！

比如工程中需要引入A、B，而A依赖1.0版本的C，B依赖2.0版本的C，那么问题来了，C使用的版本将由引入A、B的顺序而定？这显然不靠谱！如果A的依赖写在B的依赖后面，将意味着最后引入的是1.0版本的C，很可能在运行阶段出现类（ClassNotFoundException）、方法（NoSuchMethodError）找不到的错误（因为B使用的是高版本的C）！

依赖传递（transitive）、Maven的最近依赖策略。

1、依赖传递：如果A依赖B，B依赖C，那么引入A，意味着B和C都会被引入。
2、Maven的最近依赖策略：如果一个项目依赖相同的groupId、artifactId的多个版本，那么在依赖树（mvn dependency:tree）中离项目最近的那个版本将会被使用。

如何处理依赖冲突呢？

• 想法1：要使用哪个版本，我们是清楚的，那么能不能不管如何依赖传递，都可以进行版本锁定呢？
  使用 [这种主要用于子模块的版本一致性中]

• 想法2：在依赖传递中，能不能去掉我们不想依赖的？
  使用 [在实际中我们可以在IDEA中直接利用插件帮助我们生成]

• 想法3：既然是最近依赖策略，那么我们就直接使用显式依赖指定版本，那不就是最靠近项目的么？
  使用

• 引入依赖的最佳实践，提前发现问题！
  那么先通过mvn dependency:tree命令形成依赖树，看看我们新加入的依赖，是否存在传递依赖，传递依赖中是否和依赖树中的版本存在冲突，如果存在多个版本冲突，利用上文的方式进行解决！

4、关于scope依赖范围

有些依赖只用于测试，比如junit；有些依赖编译用不到，只有运行的时候才能用到，比如mysql的驱动包在编译期就用不到（编译期用的是JDBC接口），而是在运行时用到的；还有些依赖，编译期要用到，而运行期不需要提供，因为有些容器已经提供了，比如servlet-api在tomcat中已经提供了，我们只需要的是编译期提供而已。

provided：编译期有效，运行期不需要提供，不会打入包中。
compile：默认的scope，运行期有效，需要打入包中。
runtime：编译不需要，在运行期有效，需要导入包中。（接口与实现分离）
test：测试需要，不会打入包中。