Maven生命周期
通过IDEA工具的辅助,能很轻易看见Maven的九种生命周期命令,如下:
双击其中任何一个,都会执行相应的Maven构建动作,为啥IDEA能实现这个功能呢?道理很简单,因为IDEA封装了Maven提供的命令,如:点击图中的clean,本质是在当前目录中,执行了mvn clean命令,下面解释一下每个命令的作用:
clean:清除当前工程编译后生成的文件(即删除target整个目录);
当我们执行构建操作(如编译、测试、打包等)时,会生成一些中间结果和最终产物,这些文件通常存放在项目根目录下的target目录中。通过运行mvn clean命令,Maven会首先执行clean生命周期中的clean阶段,清理整个target目录下的内容,不会动依赖的jar包。这样做可以确保在进行下一次构建时,之前的编译结果和生成的文件都被彻底清除,从而保证了一个干净的构建环境。
validate:对工程进行基础验证,如工程结构、pom、资源文件等是否正确;
在执行Maven构建时,当进入到validate阶段时,Maven会检查项目的一些基本信息和配置是否存在问题或错误。例如,它会验证项目的目录结构是否符合规范,是否包含所需的源代码和资源文件,以及项目的POM文件是否正确配置了必要的依赖、插件和属性等。通过执行mvn validate命令或作为构建过程中较早的一个阶段,可以触发validate阶段的执行。如果在该阶段检测到任何问题或错误,Maven将报告相应的错误消息,并停止后续构建过程。验证阶段的目的是确保项目的基础设置和配置是正确的,以便能够顺利执行后续的编译、测试、打包等构建任务。它有助于提前发现并解决项目配置方面的问题,以避免在后续构建过程中出现潜在的错误或异常。
compile:对src/main/java目录下的源码进行编译(会生成target目录);
compile是默认生命周期中的一个阶段,用于对项目中的源代码进行编译。该阶段主要负责编译位于src/main/java目录下的Java源码文件。当执行Maven构建时,当进入到compile阶段时,Maven会使用Java编译器(例如Javac)将src/main/java目录下的源代码文件编译为字节码文件(.class文件)。编译后的结果会被输出到项目的target目录下。通过执行mvn compile命令或作为构建过程中的一个阶段,可以触发compile阶段的执行。如果在该阶段编译过程中发现了源代码的语法错误或其他问题,Maven将报告相应的错误消息,并停止构建过程。
test:编译并执行src/test/java/目录下的所有测试用例;
执行 src/test/java/ 目录下的所有测试用例通常意味着执行其中使用了 @Test 注解标记的方法,以验证代码的正确性和稳定性。
package:将当前项目打包,普通项目打jar包,webapp项目打war包;
将项目打包是指将项目的源代码、配置文件和依赖库等资源整合为一个可执行的文件或归档文件。打包完成的文件通常会被放置在项目的 target 目录下。这样可以方便地部署、分发和运行项目。在 Maven 中,使用 Maven 插件可以轻松地将当前项目打包成不同的形式,根据项目类型和需求,有两种常见的打包方式:对于普通项目:可以将其打包为 JAR(Java Archive)文件。JAR 文件是一种归档格式,用于存储 Java 类、资源文件和依赖库等。它可以作为一个独立的可执行文件,并可以在 Java 虚拟机上运行。使用 Maven 打包成 JAR文件时,可以包含项目的编译结果以及相关的配置文件,使其方便地被其他项目引用和调用。
对于 Web 应用程序(Web Application)项目:可以将其打包为 WAR(Web Application Archive)文件。WAR 文件是一种归档格式,用于打包和部署 Web 应用程序。它可以包含项目的编译结果、Web 资源、Servlet、JSP 页面、静态文件等,并可以在支持 Java Servlet 规范的 Web 容器中运行。使用 Maven 打包成 WAR 文件时,通常会将项目打包为一个独立可部署的文件,以便于在 Web 服务器上进行部署和发布。
verify:验证工程所有代码、配置进行是否正确,如类中代码的语法检测等;
经过了编译打包,可能会出错,所以再检查一遍。
verify 是软件开发中的一个步骤,用于验证工程中的代码和配置是否正确。它通常包括对代码进行语法检测、静态分析和其他类型的自动化检查,以确保代码的质量和一致性。 在软件开发过程中,为了减少错误和提高代码的可维护性,开发人员可以使用各种工具和技术来进行代码验证。
以下是一些常见的代码验证方法:
语法检查:通过使用编译器或静态代码分析工具,可以检查代码是否符合编程语言的语法规范。这些工具可以捕获语法错误、拼写错误和常见的语义错误。
静态代码分析:静态代码分析工具可以对代码进行详细的检查,以查找潜在的问题和缺陷。例如,它可以检测未使用的变量、空指针引用、不良的编程实践等。
代码风格检查:代码风格指定了代码的书写规范,如缩进、命名约定、注释规范等。通过使用代码风格检查工具,可以确保项目中的所有代码都遵循统一的代码风格。
单元测试:单元测试是用于验证单个函数、类或模块的行为是否正确的测试方法。通过编写和执行单元测试,可以检验代码是否按预期工作,并捕获潜在的缺陷。
集成测试:集成测试是用于验证组件之间的交互和整体系统的功能的测试方法。它可以确保各个模块在集成时能够正常工作,并发现可能存在的集成问题。
通过进行代码验证,开发人员可以及早发现并解决问题,提高代码质量,减少后续调试和修复的工作量。
install:将当前工程打包,然后安装到本地仓库,别人可通过GAV导入;
install是指将当前项目打包,并将该打包文件安装到本地仓库中,以便其他人可以通过引入该项目的GAV(Group/Artifact/Version)信息也就是依赖dependency来使用该项目。
具体步骤如下:
打包:首先,使用构建工具(如Maven或Gradle)执行打包命令,将项目的源代码编译为可执行文件或可部署的包。打包过程会根据项目的配置文件生成相应的构建产物。
安装:然后,使用构建工具执行"install"命令,将项目的打包文件安装到本地仓库。本地仓库通常位于开发人员的计算机上,用于存储和管理本地构建和依赖项。
导入:其他开发人员可以通过在其项目的配置文件中添加对该项目的 GAV 信息来导入该项目。GAV包括"Group"(组织)、“Artifact”(项目名称)和"Version"(版本号)等标识符,用于唯一标识一个特定的项目。
通过执行"install"命令并将项目安装到本地仓库,可以使其他开发人员能够方便地引入并使用该项目作为依赖项。这样做的好处是,避免了每个项目都需要重新构建和打包依赖项的麻烦,提高了开发效率和代码复用性。
一般在为服务项目中我们一般会设置一个commons基础模块,用来做一些公共的东西和通用的依赖,然后让其他模块引用这个模块的依赖。
site:生成项目的概述、源码测试覆盖率、开发者列表等站点文档(需要额外配置);
site是指生成项目的站点文档,其中包括项目概述、源码测试覆盖率报告、开发者列表等信息。 生成站点文档需要进行额外的配置和操作。
通常情况下,使用构建工具(如Maven或Gradle)执行"site"命令可以生成项目的站点文档。以下是一些常见的站点文档内容:
项目概述:包括项目的描述、目标、功能特性等信息,用于向用户和其他开发人员介绍项目的基本情况和背景。源码测试覆盖率报告:通过运行单元测试并对代码进行分析,生成源码测试覆盖率报告。该报告显示了测试用例对项目代码的覆盖程度,帮助开发人员评估测试的完整性和质量。
开发者列表:列出了参与项目开发的开发人员列表,包括他们的姓名、联系方式等信息。这样可以让其他人知道哪些开发人员参与了项目,方便合作和交流。
通过生成站点文档,开发人员可以将项目的相关信息以易读且友好的方式展现出来,方便项目的理解、文档查阅和协作。此外,站点文档也可以作为项目的官方文档发布和分享。需要注意的是,生成站点文档通常需要根据项目的需要进行额外的配置和设置。具体的配置方法可以参考构建工具的文档或相关教程。
deploy:将当前工程对应的包,上传到远程仓库,提供给他人使用(私服会用)。
deploy是指将当前工程对应的包或构建产物上传到远程仓库,以便他人可以从该仓库获取并使用这些包。
通常情况下,开发人员使用构建工具(如Maven或Gradle)执行"deploy"命令,将构建好的项目包或库发布到远程仓库。远程仓库可以是公共的仓库,如Maven中央仓库,也可以是私有的仓库,如企业内部搭建的私服。
以下是"deploy"的一些关键概念和流程:
包或构建产物:在软件开发中,项目经过构建打包之后会生成相应的包或构建产物,用来提供给其他开发人员使用。这些包可以是可执行文件、库文件、插件等,根据项目类型和需求而定。
远程仓库:远程仓库是存储和管理包和构建产物的地方,以供他人进行访问和下载。公共远程仓库(如Maven中央仓库)通常包含了大量的开源包供社区使用,而私有远程仓库(如企业内部私服)则用于存储特定组织或项目的包。
配置认证信息:为了能够向远程仓库发布内容,需要在构建工具的配置文件中提供相应的认证信息,如用户名和密码。这些信息用于验证发布者的身份,并确保只有授权用户才能上传内容。
通过执行"deploy"命令并提供认证信息,开发人员可以将当前工程对应的包或构建产物上传到远程仓库,使他人可以方便地获取和使用这些软件资源。这样做的好处是,避免了每个开发人员都需要重新构建和打包项目的麻烦,提高了代码的复用性和共享性。
需要注意的是,执行"deploy"命令需要确保远程仓库的地址和认证信息正确配置,并且具备相应的权限和访问权限。
Maven划分的三套生命周期:
主要看default这套,该生命周期涵盖了构建过程中的检测、编译、测试、打包、验证、安装、部署每个阶段。注意一点:同一生命周期内,执行后面的命令,前面的所有命令会自动执行!
比如现在执行一条命令:
mvn test
est命令位于default这个生命周期内,所以它会先执行validate、compile这两个阶段,然后才会真正执行test阶段。同时,还可以一起执行多个命令,如:
mvn clean install
这两个命令隶属于不同的周期,所以会这样执行:先执行clean周期里的pre-clean、clean,再执行default周期中,validate~install这个闭区间内的所有阶段。
从上面不难发现,default是Maven的核心周期,但其实上面并没有给完整,因为官方定义的default一共包含23个小阶段,上面的图只列出了七个核心周期,对详细阶段感兴趣的可以自行了解。
Maven中只定义了三套生命周期,以及每套周期会包含哪些阶段,而每个阶段具体执行的操作,这会交给插件去干,也就是说:Maven插件会实现生命周期中的每个阶段,这也是大家为什么看到IDEA的Lifecycle下面,还会有个Plugins的原因:
当你双击Lifecycle中的某个生命周期阶段,实际会调用Plugins中对应的插件。在Shell窗口执行mvn命令时,亦是如此,因为插件对应的实现包,都会以jar包形式存储在本地仓库里。