maven依赖(maven7)

版权声明: https://blog.csdn.net/qq_39769369/article/details/84246223

一、生命周期

①构建过程中的环节执行顺序:不能打乱顺序,必须按照既定的正确的顺序来执行

②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

猜你喜欢

转载自blog.csdn.net/qq_39769369/article/details/84246223