Maven 是一个Java项目管理工具,主要功能是统一开发规范与包的依赖管理。
2.1、Maven名词解释
1. POM(Project Object Model)项目对象模型
Maven项目对象模型(POM),可以通过一小段描述信息来管理项目的构建,报告和文档的软件项目管理工具。
POM 与 Java 代码实现了解耦,当需要升级版本时,只需要修改POM,而不需要更改Java代码,而在POM稳定后,日常的Java代码开发基本不涉及POM的修改。
2. 坐标
groupId , artifactId , version 三个元素是项目的坐标,唯一的标识这个项目。
groupId 项目所在组,一般是组织或公司
artifactId 是当前项目在组中的唯一ID;
version 表示版本,SNAPSHOT表示快照,表示此项目还在开发中,不稳定。
groupId 和实际项目不一定是一一对应的,maven 有模块的概念,例如 spring-core, spring-context...;groupId 也不应该只对应公司或组织名,建议具体到项目名,因为公司或者组织下有多个项目,而artifactId只能代表模块名。
<!-- 定义本项目的依赖关系 -->
<dependencies>
<!-- 每个dependency都对应这一个jar包 -->
<dependency>
<!--一般情况下,maven是通过groupId、artifactId、version这三个元素值(俗称坐标)来检索该构件, 然后引入你的工程。
如果别人想引用你现在开发的这个项目(前提是已开发完毕并发布到了远程仓库),-->
<!--就需要在他的pom文件中新建一个dependency节点,将本项目的groupId、artifactId、version写入, maven就会把你上传的jar包下载到他的本地 -->
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<!-- 设置指依赖是否可选,默认为false,即子项目默认都继承:为true,则子项目必需显示的引入,与dependencyManagement里定义的依赖类似 -->
<optional>true</optional>
<!-- maven认为,程序对外部的依赖会随着程序的所处阶段和应用场景而变化,所以maven中的依赖关系有作用域(scope)的限制。 -->
<!--scope包含如下的取值:compile(编译范围)、provided(已提供范围)、runtime(运行时范围)、test(测试范围)、system(系统范围) -->
</dependency>
</dependencies>
3.依赖范围
- compile : 编译,测试,运行都有效,默认的选择
- test : 测试有效,例如junit
- provided : 编译,测试有效,例如 servlet ,运行时容器会提供实现
- runtime : 运行和测试有效,例如 jdbc,编译时只需相应的接口,测试和运行时才需要具体的实现
- system : 编译,测试有效。使用此范围的依赖必须通过systemPath元素显式的指定依赖文件,因而
此类依赖是不通过Maven仓库解析的,一般适合于本机测试环境下,依赖本地起的服务。
4.构建
maven支持许多种的应用程序类型,对于每一种支持的应用程序类型都定义好了一组构建规则和工具集。
5.输出管理
maven可以管理项目构建的产物,并将其加入到用户库中。这个功能可以用于项目组和其他部门之间的交付行为
6.依赖关系
maven对依赖关系的特性进行细致的分析和划分,避免开发过程中的依赖混乱和相互污染行为
7.文档和构建结果
maven的site命令支持各种文档信息的发布,包括构建过程的各种输出,javadoc,产品文档等。
8.项目关系
一个大型的项目通常有几个小项目或者模块组成,用maven可以很方便地管理
9.移植性管理
maven可以针对不同的开发场景,输出不同种类的输出结果
-
Project: 项目
- 任何你想 build 的事物,Maven都会把它们当作是一个 Project。
- 这些 Project 被定义为 POM(Project Object Model)。
- 一个 Project 可以依赖其他的project,一个 project 也可以有多个子project组成。
-
POM:文档对象模型
-
- POM(pom.xml) 是 Maven 的核心文件,它是指示 Maven 如何工作的元数据文件,类似 ant 的 build.xml 文件。
- pom.xml 文件应该位于每个 Project 的根目录。
-
GroupId: 组织号
-
- 顾名思义,这个应该是公司名或组织名。
-
ArtifactId:项目名
- 构建出来的文件名,一般来说或,这个也是project名。
-
Packaging:打包
- 项目打包的类型,可以是将jar、war、rar、ear、pom,默认是jar。
-
Version:版本
- 项目的版本,项目的唯一标识由 groupId+artifactId+packaging+versionz 组成。
-
Dependency: 依赖
- 为了能够 build 或运行,一个典型的java project会依赖其他的包,在Maven中,这些被依赖的包就被称为 dependency。
-
Plug-in:插件
- Maven是有插件组织的,它的每一个功能都是由插件提供的,主要的插件是由 java 来写的,但是他也支持 beanshell 和 ant 脚本编写的插件。
-
Repository:仓库
- 仓库用来存放artifact的,可以是本地仓库,也可以是远程仓库,Maven是由一个默认的仓库
-
Snapshot:快照
- 工程中可以(也应该)有这样一个特殊的版本:这个版本可以告诉Maven,该工程正在处于开发阶段,会经常更新(但还为发布)。当其他工程依赖此类型的artifact时,Maven会在仓库中寻找该artifact的最新版本,并自动下载、使用该最新版本。
2.2、Maven的生命周期
maven把项目的构建划分为不同的生命周期(lifecycle)。粗略一点的话,它这个过程(phase)包括:编译、测试、打包、集成测试、验证、部署。maven中所有的执行动作(goal)都需要指明自己在这个过程中的执行位置,然后maven执行的时候,就依照过程的发展依次调用这些goal进行各种处理。
这个也是maven的一个基本调度机制。一般来说,位置稍后的过程都会依赖于之前的过程。当然,maven同样提供了配置文件,可以依照用户要求,跳过某些阶段。
三种生命周期
- Clean Lifecycle 在进行真正的构建之前进行一些清理工作。
- Default Lifecycle 构建的核心部分,编译,测试,打包,部署等等。
- Site Lifecycle 生成项目报告,站点,发布站点。
下面列出了default、clean和site生命周期的所有构建阶段,这些阶段按照指定的顺序执行。
clean生命周期
执行阶段 | 描述说明 |
---|---|
pre-clean | 在实际的项目清理之前执行所需的过程 |
clean | 删除前一个构建生成的所有文件 |
post-clean | 执行完成项目清理所需的过程 |
Default生命周期
执行阶段 | 描述说明 |
---|---|
validate | 验证项目是正确的,所有必要的信息都是可用的。 |
initialize | 初始化构建状态,例如设置属性或创建目录。 |
generate-sources | 生成包含在编译中的任何源代码。 |
process-sources | 处理源代码,例如过滤任何值。 |
generate-resources | 生成包含在包中的资源。 |
process-resources | 将资源复制并处理到目标目录中,准备打包。 |
compile | 编译项目的源代码。 |
process-classes | 从编译后生成生成的文件,例如在Java类上执行字节码增强。 |
generate-test-sources | 生成包含在编译中的任何测试源代码。 |
process-test-sources | 处理测试源代码,例如过滤任何值。 |
generate-test-resources | 为测试创建资源。 |
process-test-resources | 将资源复制并处理到测试目标目录中。 |
test-compile | 将测试源代码编译到测试目标目录 |
process-test-classes | 从测试编译后post-process生成文件,例如在Java类上执行字节码增强。对于Maven 2.0.5和以上。 |
test | 使用合适的单元测试框架运行测试。这些测试不应该要求打包或部署代码。 |
prepare-package | 在实际包装前执行必要的准备工作。这通常会导致包的一个未打包的、经过处理的版本。(Maven 2.1及以上) |
package | 使用已编译的代码,并将其打包成可部署格式,例如JAR。 |
pre-integration-test | 执行集成测试之前需要执行的操作。这可能涉及到设置所需的环境等问题。 |
integration-test | 在需要集成测试的环境中,处理并部署包。 |
post-integration-test | 执行集成测试后所需要的操作。这可能包括清理环境。 |
verify | 运行任何检查以验证包是否有效,并满足质量标准。 |
install | 将该包安装到本地存储库中,作为本地其他项目的依赖项。 |
deploy | 在集成或发布环境中完成,将最终包复制到远程存储库中,以便与其他开发人员和项目共享。 |
Site生命周期
执行阶段 | 描述说明 |
---|---|
pre-site | 在实际的项目站点生成之前执行过程 |
site | 生成项目的站点文档 |
post-site | 执行确定站点生成的过程,并为站点部署做好准备 |
site-deploy | 将生成的站点文档部署到指定的web服务器 |
注意:执行某个生命周期的某个阶段不会影响其它的生命周期!
如果要同时执行多个生命周期的阶段可在命令行输入多个命令,中间以空格隔开,例如: clean package 该命令执行clean生命周期的clean阶段和default生命周期的package阶段。
2.3、Maven标准工程结构
Maven的标准工程结构如下:
2.4、Maven的"约束优于配置"
所谓的"约束优于配置",在maven中并不是完全不可以修改的,他们只是一些配置的默认值而已。但是除非必要,并不需要去修改那些约定内容。maven默认的文件存放结构如1.3所示。
每一个阶段的任务都知道怎么正确完成自己的工作,比如compile任务就知道从src/main/java下编译所有的java文件,并把它的输出class文件存放到target/classes中。
对maven来说,采用"约定优于配置"的策略可以减少修改配置的工作量,也可以降低学习成本,更重要的是,给项目引入了统一的规范。
2.5、Maven的版本规范
maven有自己的版本规范,一般是如下定义
maven在版本管理时候可以使用几个特殊的字符串 SNAPSHOT,LATEST,RELEASE。比如"1.0-SNAPSHOT"。各个部分的含义和处理逻辑如下说明:
SNAPSHOT
这个版本一般用于开发过程中,表示不稳定的版本。
LATEST
指某个特定构件的最新发布,这个发布可能是一个发布版,也可能是一个snapshot版,具体看哪个时间最后。
RELEASE
是指仓库中最后的一个非快照版本
规范:
- 同一项目中所有模块版本保持一致
- 子模块统一继承父模块的版本
- 统一在顶层模块Pom的
节中定义所有子模块的依赖版本号,子模块中添加依赖时不要添加版本号 - 开发测试阶段使用SNAPSHOT
- 生产发布使用RELEASE
- 新版本迭代只修改顶层POM中的版本
2.6、项目骨架Maven Archetype
什么是Maven Archetype? 简单的说就是一个Maven项目的基础模板,利用这个模板我们就可快速的建立一个新的该类型项目,同时也可以建立自己的项目骨架。
Maven所提供的archetype功能都是由插件Maven Archetype Plugin完成的
官网地址:http://maven.apache.org/archetype/maven-archetype-plugin/
主要命令:
- archetype:generate 从项目骨架创建一个maven项目,老版本里使用的是archetype:create
- archetype:create-from-project 根据一个项目创建项目骨架
使用archetype:generate创建项目
mvn archetype:generate命令参数解释
项目相关参数:
参数 | 含义 |
---|---|
groupId | 当前应用程序隶属的Group的ID |
artifactId | 当前应用程序的ID |
package | 代码生成时使用的根包的名字,如果没有给出,默认使用archetypeGroupId |
原型有关参数表
参数 | 含义 |
---|---|
archetypeGroupId | 原型(archetype)的Group ID |
archetypeArtifactId | 原型(archetype)ID |
archetypeVersion | 原型(archetype)版本 |
archetypeRepository | 包含原型(archetype)的资源库 |
archetypeCatalog | archetype分类,这里按位置分类有: ‘local’ 本地,通常是本地仓库的archetype-catalog.xml文件 ‘remote’ 远程,是maven的*仓库 file://...' 直接指定本地文件位置archetype-catalog.xml http://...' or 'https://...' 网络上的文件位置 archetype-catalog.xml 'internal' 默认值是remote,local |
filter | 查找时过滤artifactId or groupId:artifactId |
package | 代码生成时使用的根包的名字,如果没有给出,默认使用archetypeGroupId |
2.7、maven的项目对象模型
Maven包含了一个项目对象模型 (Project Object Model),一组标准集合,一个项目生命周期(Project Lifecycle),一个依赖管理系统(Dependency Management System),和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。
项目对象模型 (Project Object Model)
一个maven工程都有一个pom.xml文件,通过pom.xml文件定义项目的坐标、项目依赖、项目信息、插件目标等。
依赖管理系统(Dependency Management System)
通过maven的依赖管理对项目所依赖的jar 包进行统一管理。
一个项目生命周期(Project Lifecycle)
使用maven完成项目的构建,项目构建包括:清理、编译、测试、部署等过程,maven将这些过程规范为一个生命周期,如下所示是生命周期的各各阶段:
maven通过执行一些简单命令即可实现上边生命周期的各各过程,比如执行mvn compile执行编译、执行mvn clean执行清理。
一组标准集合
maven将整个项目管理过程定义一组标准,比如:通过maven构建工程有标准的目录结构,有标准的生命周期阶段、依赖管理有标准的坐标定义等。
插件(plugin)目标(goal)
maven 管理项目生命周期过程都是基于插件完成的。
Maven坐标是一组可以惟一标识构件的三元组值
-
groupId,代表构件的实体或组织例如:org.inspur.loushang
-
artifactId,实际的构件的名称,例如framework
-
version,该构件件的版本号
-
packaging :定义Maven项目打包的方式,首先,打包方式通常与所生成构件的文件扩展名对应,如上例中的packaging为jar,最终的文件名为my-app-0.0.1-SNAPSHOT.jar。也可以打包成war, ear等。当不定义packaging的时候,Maven 会使用默认值jar
classifier: 该元素用来帮助定义构建输出的一些附件。附属构件与主构件对应,如上例中的主构件为my-app-0.0.1-SNAPSHOT.jar,该项目可能还会通过一些插件生成如my-app-0.0.1-SNAPSHOT-javadoc.jar,my-app-0.0.1-SNAPSHOT-sources.jar, 这样附属构件也就拥有了自己唯一的坐标