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。(一般不使用)