一、生命周期
①构建过程中的环节执行顺序:不能打乱顺序,必须按照既定的正确的顺序来执行
②Maven的核心程序中定义了抽象的生命周期,生命周期的各个阶段的具体任务是由插件来完成的
③Maven 有三套相互独立的生命周期,分别是:
-
Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
-
Default Lifecycle 构建的核心部分,编译,测试,打包,安装,部署等等。
-
Site Lifecycle 生成项目报告,站点,发布站点。
它们是相互独立的,你可以仅仅调用 clean 来清理工作目录,仅仅调用 site 来生成站点。当然你也可以直接运行 mvn clean install site 运行所有这三套生命周期。
每套生命周期都由一组阶段(Phase)组成,我们平时在命令行输入的命令总会对应于一个特定的阶段。比如,运行 mvn clean,这个 clean 是 Clean 生命周期的一个阶段。有 Clean 生命周期的一个阶段。有 Clean 生命周期,也有 clean 阶段。
Clean Lifecycle和 Site Lifecycle都不太重要,最重要的是 Default Lifecycle这个生命周期里,绝大部分工作都发生在这个生命周期中。这里,只解释一些比较重要和常用的阶段
validate
generate-sources
process-sources
generate-resources
process-resources 复制并处理资源文件,至目标目录,准备打包。
compile 编译项目的源代码
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 复制并处理资源文件,至目标测试目录
test-compile 编译测试源代码。
process-test-classes
test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
prepare-package
package 接受编译好的代码,打包成可发布的格式,如 JAR。
pre-integration-test
integration-test
post-integration-test
verify
install 将包安装至本地仓库,以让其它项目依赖。
deploy 将最终的包复制到远程的仓库,以让其它开发人员与项目共享或部署到服务器上运行。
④Maven核心程序,为了更好的实现自动化构建,按照这样的特点执行生命周期中的各个阶段:无论现在要执行生命周期中的那一阶段,它前面的所有阶段都会被运行,就是都是从这个生命周期最初的位置开始执行,例如我们运行 mvn install 的时候,代码会被编译,测试,打包,例如
mvn compile |
maven-resources-plugin:2.6:resources maven-compiler-plugin:2.5.1:compile |
mvn test 执行该命产生的命令 |
maven-resources-plugin:2.6:resources maven-compiler-plugin:2.5.1:compile maven-resources-plugin:2.6:testResources maven-compiler-plugin:2.5.1:testCompile maven-surefire-plugin:2.12.4:test ---执行测试 测试报告 |
mvn package |
maven-resources-plugin:2.6:resources maven-compiler-plugin:2.5.1:compile maven-resources-plugin:2.6:testResources maven-compiler-plugin:2.5.1:testCompile maven-surefire-plugin:2.12.4:test 测试报告 maven-jar-plugin:2.4:jar |
⑤插件和目标
【1】生命周期的各个阶段仅仅定义要要执行的任务是什么。
【2】各个阶段和插件的目标是对应的
【3】相似的目标由特定的插件来完成
生命周期的阶段 | 插件目标 | 插件 |
compile | compile | maven-compiler-plugin |
testCompile | testCompile | maven-compiler-plugin |
【4】可以将目标看做调用插件的命令
二、依赖【初步】
① 一个maven项目依赖另一个maven项目
maven解析依赖信息时会到本地仓库中查找被依赖的jar包。
对于我们自己开发的maven工程,使用mvn install命令安装,其他maven工程可以依赖,例如:
HelloFriend工程中依赖了Hello工程
cmd进入Hello工程将其安装
再使用mvn compile 编译HelloFriend工程,否则会报错!!!!
② 依赖的范围
【1】compile范围依赖
-
对主程序是否有效 :有效
-
对测试程序是否有效:有效(test目录下的Java程序可以依赖compile范围的Java程序)
-
是否参与打包:参与
-
是否参与部署:参与(项目部署路径下面的lib有该jar包)
-
典型例子:spring-core
【2】test范围依赖(与compile对比,从程序结构角度对比)
-
对主程序是否有效 :无效(main目录下的Java程序无法依赖test范围的Java程序)
-
对测试程序是否有效:有效
-
是否参与打包:不参与
-
是否参与部署:不参与(项目部署路径下面的lib有没有这个jar包)
-
典型例子:junit测试
【3】provide范围依赖(与compile对比,从开发阶段对比)
-
provide通常为WEB工程添加的
-
对主程序是否有效 :有效
-
对测试程序是否有效:有效
-
是否参与打包:不参与(也就不参与部署)
-
典型的例子:servlet-api.jar开发的时候需要,但是部署的时候tomcat服务器有这个jar包,所以我们的会被忽略掉。
三、依赖【加强】
①依赖的传递性
具体如下图所示
优点:可以传递的依赖,不必在每个工程中都重复声明
注意:非compile范围的依赖不能够传递(就是test和provided范围的不能传递),所以若用到就得重复声明
②依赖的排除
【1】什么时候做排除:
【2】依赖排除的设置方式
获取依赖的groupId和artifactId
知道这个jar包的相关信息
③依赖原则说明
【1】作用:解决模块工程之间jar包冲突问题
【2】情景设定1:路径最短者优先原则
【3】情景设定2:路径相同时先声明者优先
④统一管理依赖的版本
【1】情景
这里Spring的jar包都是依赖的4.0.0,若果需要统一升级怎么办?手动修改不可靠
【2】建议配置方式:
-
使用prperties标签内自定义标签,统一声明版本号
-
在需要统一版本的位置,使用${自定义标签名}引用只其中的内容
【3】其实properties标签配合自定义标签声明数据的配置,并不只能用于依赖的版本信息,凡是需要统一声明然后再引用的场合都可以使用
以上通过观看谷粒学院学习视频所记录的笔记
谷粒学院学习官网:http://www.gulixueyuan.com