maven——进阶

1、什么是maven

Maven是一个跨平台的项目管理工具，主要用于基于java平台的项目构建，依赖管理。

• 从http://maven.apache.org/官网上下载最新版本的maven
• 设定path路径
  把下载下来的maven解压缩，然后有一个bin文件夹，这是一个bin的文件夹的目录
  F:\work\course\maven\maven\bin
  把该目录追加到环境变量的path中

注：Jdk必须1.6以上的版本

2、Maven打包原理

2.1、Maven中央存储库

当你建立一个 Maven 的项目，Maven 会检查你的 pom.xml 文件，以确定哪些依赖下载。首先，Maven 将从本地资源库获得 Maven 的本地资源库依赖资源，如果没有找到，然后把它会从默认的 Maven 中央存储库 http://search.maven.org/ 查找下载。
在Maven中，当你声明的库不存在于本地存储库中，也没有不存在于Maven中心储存库，该过程将停止并将错误消息输出到 Maven 控制台。

2.2、添加远程仓库

默认情况下，Maven从Maven中央仓库下载所有依赖关系。但是，有些库丢失在中央存储库，只有在Java.net或JBoss的储存库远程仓库中能找到。
现在，Maven的依赖库查询顺序更改为：
在 Maven 本地资源库中搜索，如果没有找到，进入下一步，否则退出。
在 Maven 中央存储库搜索，如果没有找到，进入下一步，否则退出。
在Maven的远程存储库搜索，如果没有找到，提示错误信息，否则退出。

3、配置私服的路径

3.1 仓库的分类

• 本地仓库：每一个用户也可以拥有一个本地仓库
• 远程仓库
  中央仓库：Maven默认的远程仓库
  私服：是一种特殊的远程仓库，它是架设在局域网内的仓库
  镜像：用来替代中央仓库，速度一般比中央仓库快

4、maven的核心概念

项目对象模型

maven根据pom.xml文件，把它转化成项目对象模型(POM)，这个时候要解析依赖关系，然后去相对应的maven库中查找到依赖的jar包。
在clean，compile，test，package等阶段都有相应的Plug-in来做这些事情。
而这些plug-in会产生一些中间产物。

Maven仓库

本地仓库——>私服——>中央仓库

• dependency的使用

jar的查找坐标: groupId、artifactId、version。
http://search.maven.org/、
http://mvnrepository.com/上进行查找确定坐标。

在实际开发中，我们经常遇到这样的场景，比如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版本！

• 依赖冲突

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

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

如何处理依赖冲突呢？

1、要使用哪个版本，我们是清楚的，那么能不能不管如何依赖传递，都可以进行版本锁定呢？

使用<dependencyManagement> [这种主要用于子模块的版本一致性中]

想法2：在依赖传递中，能不能去掉我们不想依赖的？

使用<exclusions>[在实际中我们可以在IDEA中直接利用插件帮助我们生成]

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

使用<dependency>

• 引入依赖的最佳实践，提前发现问题

在工程中，我们避免不了需要加一些依赖，也许加了依赖后运行时才发现存在依赖冲突在去解决，似乎有点晚！那么能不能提前发现问题呢？
.
如果我们新加入一个依赖的话，那么先通过mvn dependency:tree命令形成依赖树，看看我们新加入的依赖，是否存在传递依赖，传递依赖中是否和依赖树中的版本存在冲突，如果存在多个版本冲突，利用上文的方式进行解决！

• Maven的生命周期

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

• 关于scope依赖范围

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

总结来说：
compile：默认的scope，运行期有效，需要打入包中。
provided：编译期有效，运行期不需要提供，不会打入包中。
runtime：编译不需要，在运行期有效，需要导入包中。（接口与实现分离）
test：测试需要，不会打入包中。
system：非本地仓库引入、存在系统的某个路径下的jar。（一般不使用）