Maven使用说明及规范
此文档主要说明Maven的基础使用方式,以及在使用过程过程中需要遵守哪些默认的准则。我们工作中会经常写maven的配置,但是很多maven使用细节你可能并不知道,但你掌握后使用maven会更加上手。
Maven是什么?
Apache Maven是一个软件项目管理工具。基于项目对象模型(POM)的概念,Maven可以通过一小段描述信息来管理项目的构建,报告和文档。 Maven的核心是一个插件执行框架, 所有工作都是通过插件完成的。最熟悉的插件如我们比较常用的:
- clean(https://github.com/apache/maven-clean-plugin/)
- compiler(https://github.com/apache/maven-compiler-plugin/ )
- install(https://github.com/apache/maven-install-plugin/ )
- deploy(https://github.com/apache/maven-deploy-plugin/ )
除了这些默认流程的插件,我们针对Maven的工作机制也制作了自己的插件,如 授权系统抽取api.json文件的插件,如通过erm对象描述文件生成Entity实体的插件等(https://gitee.com/kekingcn/kk-erm-maven-plugin)。
基本使用
基础信息
定义pom模型的基本信息
使用Maven构建的项目,首先需要在pom.xml文件中写明基本信息,如:
由groupId、artifactId、version三个元素定位唯一的jar信息,常说的发个Maven坐标也就是这三个元素
modules 节点,聚合子模块,
在多模块的项目中使用,用来定义子模块,一般多模块项目中,父模块的packaging都定义为pom
parent节点,继承其他pom模型的属性
如:在spring boot项目中,会有如下parent节点,用来继承spring boot已经定义好的pom
properties 节点,定义属性信息
这个节点一般用于定义一些属性,用来作为插件的默认值。在这里定义的属性可以贯穿Maven build的整个生命周期,Maven属性是值占位符,可以在pom中通过${XXX}符号来使用
除了如上手动定义的一些属性,我们还可以通过如下的方式,访问到其他的一些变量,如:
- env.X : 使用“env.”对变量进行前缀。将返回shell的环境变量。例如,$ {env.PATH}包含PATH环境变量。 注意:虽然环境变量本身在Windows上不区分大小写,但属性的查找区分大小写。换句话说,当Windows shell为%PATH%和%Path%返回相同的值时,Maven会区分$ {env.PATH}和$ {env.Path}。从Maven 2.1.0开始,为了可靠性,环境变量的名称被归一化为所有大写。
- project.x : POM中的标记路径将包含相应元素的值。例如:<project> <version> 1.0 </ version> </ project>可通过$ {project.version}访问。
- settings.x : Mavne Home路径的settings.xml将包含相应的元素的值。例如:<settings> <offline> false </ offline> </ settings>可通过$ {settings.offline}访问。
- Java系统属性 : 通过java.lang.System.getProperties()访问的所有属性都可用作POM属性,例如${java.home}。
dependencies 节点,定义项目依赖
除了基本的groupId、artifactId、version坐标属性外,dependency节点中还包括如下的常用属性设置
- type : 依赖的类型,默认是jar
- classifier : 分类器,额外的jar坐标标记,用来依赖那些从同一个POM中打出的不同的jar包。
- scope : 依赖的jar的作用范围,可选(compile,runtime,test,system,provided)
compile : 这是默认范围。所有类路径中都提供了编译依赖项。此外,这些依赖项将传播到依赖项目
runtime : 这很像compile,但表示您希望JDK或容器在运行时提供它。它仅在编译和测试类路径中可用,并且不可传递。
test : 此范围表示正常使用应用程序不需要依赖项,并且仅适用于测试编译和执行阶段。它不是传递性的。
provided :这很像compile,但表示您希望JDK或容器在运行时提供它。它仅在编译和测试类路径中可用,并且不可传递。
system :此范围与provided的类似,只是您必须提供明确包含它的JAR,声明后不会在存储库中查找
- Systempath:当scope为system生效,用于定义本地依赖的路径
- optional :是否启用依赖传递,默认false需要依赖传递。如A依赖B,B依赖C,默认情况下A中会有C的依赖,如果在依赖B时设置optional为true,则A中不会有C的依赖
- exclusions :排除依赖传递
dependencies -> exclusions 节点,排除依赖传递
有时候为了解决项目依赖冲突,需要排除依赖的jar包通过Maven依赖传递特性引用的其他jar,如:
关于Maven依赖传递特性,当出现多个jar依赖相同的不同版本jar时,遵循两个原则来引用:
- 最短路径原则:如A->B->C-D1 , A->B1->D2 , 那么最终项目A依赖的D的版本是D2。
- 最先定义原则: 如A->B->D1 , A->C->D2 , 那么最终项目A雨来的D的版本是D1.
dependencyManagement 节点,声明依赖项
dependencyManagement用来管理声明依赖项,最常见于spring boot项目中,在依赖节点只需要写groupId、artifactId就可以定位一个jar坐标,是因为spring boot的父pom中使用dependencyManagement声明了常用的依赖项,如:
使用dependencyManagement管理的依赖只是声明了,如果没有显示的定义在< dependencies >节点中是不生效的
profiles -> profile 节点,定义不同环境的构建属性
在软件项目迭代中,通常会有开发、测试、生产等不同的运行环境。很多时候不同的环境需要不同的依赖属性,诸如此场景,都可以使用profiles来定义不同环境下的变量,如:
repositories、pluginRepositories 节点,定义依赖和插件的仓库地址
这里可以定义jar拉取的仓库地址,除了Apache中央仓库外,还有很多其他的开源仓库,如spring的,
构建信息
build 节点,设置输入输出路径
为什么在使用Maven构建的项目中,项目编译后会在pom所在目录下生成target目录?是因为在build构建节点中有如下的默认的配置。当然,如果你显示配置了如下的属性,就可以指定编译后文件的输出目录
build -> resources,定义项目资源
resources用来定义项目的资源路径,默认的路径为${basedir}/src/main/resources,在spring boot环境中,继承了spring boot的父pom属性,它的resources定义如下:
可以看到,spring boot中只定义了三种文件类型的资源,而且通配application开头的文件。当项目中有其他的文件类型或不是application开头时,Maven就会过滤掉。而且在spring boot中定义了属性占位符为@符号,所以在资源文件中使用${}时并不会生效。为了解决这个问题,可以自己在pom中定义resources属性覆盖父pom的行为:如,
build -> plugins -> plugin,定义构建插件
plugin这个节点主要用来定义构建的插件,包括自定义和已经发布到中央仓库的。如spring boot环境想构建可执行的jar需要添加spring-boot-maven-plugin插件。
更多可用的插件:http://maven.apache.org/plugins/index.html
distributionManagement 节点,配置deploy的仓库地址
当我们自己搭建了私服,想要将jar包编译后上传到私服时,需要在这个节点配置仓库的地址,如:
项目信息
根节点下的name、description、url等节点
根节点下的name、description、url等节点用来描述项目的基本信息,如:
Licenses节点,描述许可证信息
Organization节点,描述组织信息
省略....
遵守的准则规范
Maven坐标version属性设置
一般建议在开发和测试环境中的jar,打成SNAPSHOT的,生产环境的版本打成RELEASES的,这个可以通过上面的profiles节点来控制,他们的区别如下:
- SNAPSHOT :当版本号带’-SNAPSHOT’后缀时,既定义发布的jar为快照版本,应用在依赖时,总是会拉取最新的快照版本。
- RELEASES :当版本号带’-RELEASES’后缀时,既定义发布的jar为发行版,应用依赖时,首次会从远程仓库拉取,当本地仓库已有时,就不会从远程仓库拉最新的依赖了。RELEASES版本的每次更新必须指定版本号。
开发中的api模块,需要deploy
应用有些模块需要提供给别人依赖,比如api模块、common模块等。在开发时,每次接口有变动时,记得mvn deploy下,把jar上传到私服。
依赖的jar的版本使用属性控制
建议依赖别的jar时,不要写死jar的版本,通过properties节点定义的属性来控制,那么当你pom被别人依赖时,上层pom可以通过定义属性值覆盖父pom中属性来控制依赖的版本
多模块项目时,模块命名规范
在多模块时,子模块的命名建议使用父模块作为前缀,如sales系统,api模块为sales-api,app模块为sales-app