继续补充Java知识
Maven Repository: Search/Browse/Explore (mvnrepository.com)
前言
Maven 翻译为”专家”、”内行”,是 Apache 下的一个纯 Java 开发的开源项目。基于项目对象模型(缩写:POM)概念,Maven利用一个中央信息片断能管理一个项目的构建、报告和文档等步骤。
Maven 是一个项目管理工具,可以对 Java 项目进行构建、依赖管理。
Maven 也可被用于构建和管理各种项目,例如 C#,Ruby,Scala 和其他语言编写的项目。Maven 曾是 Jakarta 项目的子项目,现为由 Apache 软件基金会主持的独立 Apache 项目。
Maven 能够帮助开发者完成以下工作:
- 构建
- 文档生成
- 报告
- 依赖
- SCMs
- 发布
- 分发
- 邮件列表
Maven 特点
- 项目设置遵循统一的规则。
- 任意工程中共享。
- 依赖管理包括自动更新。
- 一个庞大且不断增长的库。
- 可扩展,能够轻松编写 Java 或脚本语言的插件。
- 只需很少或不需要额外配置即可即时访问新功能。
- 基于模型的构建 − Maven能够将任意数量的项目构建到预定义的输出类型中,如 JAR,WAR 或基于项目元数据的分发,而不需要在大多数情况下执行任何脚本。
- 项目信息的一致性站点 − 使用与构建过程相同的元数据,Maven 能够生成一个网站或PDF,包括您要添加的任何文档,并添加到关于项目开发状态的标准报告中。
- 发布管理和发布单独的输出 − Maven 将不需要额外的配置,就可以与源代码管理系统(如 Subversion 或 Git)集成,并可以基于某个标签管理项目的发布。它也可以将其发布到分发位置供其他项目使用。Maven 能够发布单独的输出,如 JAR,包含其他依赖和文档的归档,或者作为源代码发布。
- 向后兼容性 − 您可以很轻松的从旧版本 Maven 的多个模块移植到 Maven 3 中。
- 子项目使用父项目依赖时,正常情况子项目应该继承父项目依赖,无需使用版本号,
- 并行构建 − 编译的速度能普遍提高20 - 50 %。
- 更好的错误报告 − Maven 改进了错误报告,它为您提供了 Maven wiki 页面的链接,您可以点击链接查看错误的完整描述。
Maven软件的安装和配置
1)下载maven的安装包。
最好下载:apche-maven-3.3.9-bin.zip版本。目前使用也最为广泛。
下载地址:Maven – Download Apache Maven
2)解压文件,解压到一个非中文目录。
子目录conf:maven工具的配置文件 settings.xml。
子目录bin:执行程序,主要是mvn.cmd.
3)配置环境变量添加环境变量 MAVEN_HOME:
系统 | 配置 |
---|---|
Windows | 右键 “计算机”,选择 “属性”,之后点击 “高级系统设置”,点击”环境变量”,来设置环境变量,有以下系统变量需要配置:新建系统变量 MAVEN_HOME,变量值:E:\Maven\apache-maven-3.3.9编辑系统变量 Path,添加变量值:**;%MAVEN_HOME%\bin**注意:注意多个值之间需要有分号隔开,然后点击确定。 |
4)打开dos窗口,输入mvn -v出现
约定配置
Maven 提倡使用一个共同的标准目录结构,Maven 使用约定优于配置的原则,大家尽可能的遵守这样的目录结构。如下所示:
目录 | 目的 |
---|---|
${basedir} | 存放pom.xml和所有的子目录 |
${basedir}/src/main/java | 项目的java源代码 |
${basedir}/src/main/resources | 项目的资源,比如说property文件,springmvc.xml |
${basedir}/src/test/java | 项目的测试类,比如说Junit代码 |
${basedir}/src/test/resources | 测试用的资源 |
${basedir}/src/main/webapp/WEB-INF | web应用文件目录,web项目的信息,比如存放web.xml、本地图片、jsp视图页面 |
${basedir}/target | 打包输出目录 |
${basedir}/target/classes | 编译输出目录 |
${basedir}/target/test-classes | 测试编译输出目录 |
Test.java | Maven只会自动运行符合该命名规则的测试类 |
~/.m2/repository | Maven默认的本地仓库目录位置 |
1 | |-- pom.xml # Maven 项目管理文件 |
仓库
仓库的概念:
仓库是存放东西的,Maven 仓库的是:
1.Maven 的插件,插件也是一些 jar,这些 jar 可以完成一定的功能。
2.我们自己开发项目的模块
3.第三方框架或工具的 jar 包
分类说明:
1)本地仓库:本机当前电脑上的资源存储位置,为本机上所有 Maven工程提供服务。
2)远程仓库:不在本机上, 通过网络才能使用。多电脑共享使用的。
①:中央仓库:通过Internet访问,为全世界所有 Maven工程服务。 最权威的。
②:中央仓库的镜像:架设在不同位置,欧洲,美洲,亚洲等每个洲都有若干的服务器,为中央仓库分担流量。减轻中央仓库的访问,下载的压力。所在洲的用户首先访问的是本洲的镜像服务器。
③:私服:在局域网环境中部署的服务器,为当前局域网范围内的所有 Maven工程服务。公司中常常使用这种方式。
仓库的使用:
maven仓库的使用不需要认为的参与。
在 Maven 构建项目的过程中如果需要某些插件,首先会到 Maven 的本地仓库中查找,如果找到则可以直接使用;如果找不到,它会自动连接外网,到远程中央仓库中查找;如果远程仓库中能找到,则先把所需要的插件下载到本地仓库,然后再使用,并且下次再用到相同的插件也可以直接使用本地仓库的;如果没有外网或者远程仓库中也找不到,则构建失败。
Maven工程依赖下载失败错误解决
在使用 Maven 构建项目时,可能会发生依赖项下载错误的情况,主要原因有以下几种:
- 下载依赖时出现网络故障或仓库服务器宕机等原因,导致无法连接至 Maven 仓库,从而无法下载依赖。
- 依赖项的版本号或配置文件中的版本号错误,或者依赖项没有正确定义,导致 Maven 下载的依赖项与实际需要的不一致,从而引发错误。
- 本地 Maven 仓库或缓存被污染或损坏,导致 Maven 无法正确地使用现有的依赖项。
解决方案:
- 检查网络连接和 Maven 仓库服务器状态。
- 确保依赖项的版本号与项目对应的版本号匹配,并检查 POM 文件中的依赖项是否正确。
- 清除本地 Maven 仓库缓存(lastUpdated 文件),因为只要存在lastupdated缓存文件,刷新也不会重新下载。本地仓库中,根据依赖的gav属性依次向下查找文件夹,最终删除内部的文件,刷新重新下载即可!
POM
POM( Project Object Model,项目对象模型 ) 是 Maven 工程的基本工作单元,是一个XML文件,包含了项目的基本信息,用于描述项目如何构建,声明项目依赖,等等。
执行任务或目标时,Maven 会在当前目录中查找 POM。它读取 POM,获取所需的配置信息,然后执行目标。
POM 中可以指定以下配置:
- 项目依赖
- 插件
- 执行目标
- 项目构建 profile
- 项目版本
- 项目开发者列表
- 相关邮件列表信息
pom 配置一览
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
基本配置
- project -
project
是 pom.xml 中描述符的根。 - modelVersion -
modelVersion
指定 pom.xml 符合哪个版本的描述符。maven 2 和 3 只能为 4.0.0。
一般 jar 包被识别为: groupId:artifactId:version
的形式。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
maven 坐标
在 maven 中,根据 groupId
、artifactId
、version
组合成 groupId:artifactId:version
来唯一识别一个 jar 包。
groupId - 团体、组织的标识符。团体标识的约定是,它以创建这个项目的组织名称的逆向域名(reverse domain name)开头。一般对应着 java 的包结构。
artifactId - 单独项目的唯一标识符。比如我们的 tomcat、commons 等。不要在 artifactId 中包含点号(.)。
version - 一个项目的特定版本。
maven 有自己的版本规范,一般是如下定义 major version、minor version、incremental version-qualifier ,比如 1.2.3-beta-01。要说明的是,maven 自己判断版本的算法是 major、minor、incremental 部分用数字比较,qualifier 部分用字符串比较,所以要小心 alpha-2 和 alpha-15 的比较关系,最好用 alpha-02 的格式。
maven 在版本管理时候可以使用几个特殊的字符串 SNAPSHOT、LATEST、RELEASE。比如
1.0-SNAPSHOT
。各个部分的含义和处理逻辑如下说明:- SNAPSHOT - 这个版本一般用于开发过程中,表示不稳定的版本。
- LATEST - 指某个特定构件的最新发布,这个发布可能是一个发布版,也可能是一个 snapshot 版,具体看哪个时间最后。
- RELEASE :指最后一个发布版。
packaging - 项目的类型,描述了项目打包后的输出,默认是 jar。常见的输出类型为:pom, jar, maven-plugin, ejb, war, ear, rar, par。
依赖配置
dependencies
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
- groupId, artifactId, version - 和基本配置中的
groupId
、artifactId
、version
意义相同。 - type - 对应
packaging
的类型,如果不使用type
标签,maven 默认为 jar。 - scope - 此元素指的是任务的类路径(编译和运行时,测试等)以及如何限制依赖关系的传递性。有 5 种可用的限定范围:
- compile - 如果没有指定
scope
标签,maven 默认为这个范围。编译依赖关系在所有 classpath 中都可用。此外,这些依赖关系被传播到依赖项目。 - provided - 与 compile 类似,但是表示您希望 jdk 或容器在运行时提供它。它只适用于编译和测试 classpath,不可传递。
- runtime - 此范围表示编译不需要依赖关系,而是用于执行。它是在运行时和测试 classpath,但不是编译 classpath。
- test - 此范围表示正常使用应用程序不需要依赖关系,仅适用于测试编译和执行阶段。它不是传递的。
- system - 此范围与 provided 类似,除了您必须提供明确包含它的 jar。该 artifact 始终可用,并且不是在仓库中查找。
- systemPath - 仅当依赖范围是系统时才使用。否则,如果设置此元素,构建将失败。该路径必须是绝对路径,因此建议使用
propertie
来指定特定的路径,如\$ {java.home} / lib
。由于假定先前安装了系统范围依赖关系,maven 将不会检查项目的仓库,而是检查库文件是否存在。如果没有,maven 将会失败,并建议您手动下载安装。 - optional -
optional
让其他项目知道,当您使用此项目时,您不需要这种依赖性才能正常工作。 - exclusions - 包含一个或多个排除元素,每个排除元素都包含一个表示要排除的依赖关系的
groupId
和artifactId
。与可选项不同,可能或可能不会安装和使用,排除主动从依赖关系树中删除自己。
parent
maven 支持继承功能。子 POM 可以使用 parent
指定父 POM ,然后继承其配置。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
- relativePath - 注意
relativePath
元素。在搜索本地和远程存储库之前,它不是必需的,但可以用作 maven 的指示符,以首先搜索给定该项目父级的路径。
dependencyManagement
dependencyManagement
是表示依赖 jar 包的声明。即你在项目中的 dependencyManagement
下声明了依赖,maven 不会加载该依赖,dependencyManagement
声明可以被子 POM 继承。
dependencyManagement
的一个使用案例是当有父子项目的时候,父项目中可以利用 dependencyManagement
声明子项目中需要用到的依赖 jar 包,之后,当某个或者某几个子项目需要加载该依赖的时候,就可以在子项目中 dependencies
节点只配置 groupId
和 artifactId
就可以完成依赖的引用。
dependencyManagement
主要是为了统一管理依赖包的版本,确保所有子项目使用的版本一致,类似的还有plugins
和pluginManagement
。
modules
子模块列表。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
properties
属性列表。定义的属性可以在 pom.xml 文件中任意处使用。使用方式为 ${propertie}
。
1 | <project> |
构建配置
build
build 可以分为 “project build” 和 “profile build”。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
基本构建配置:
1 | <build> |
defaultGoal : 默认执行目标或阶段。如果给出了一个目标,它应该被定义为它在命令行中(如 jar:jar)。如果定义了一个阶段(如安装),也是如此。
directory :构建时的输出路径。默认为:${basedir}/target
。
finalName :这是项目的最终构建名称(不包括文件扩展名,例如:my-project-1.0.jar)
filter :定义 * .properties
文件,其中包含适用于接受其设置的资源的属性列表(如下所述)。换句话说,过滤器文件中定义的“name = value”对在代码中替换\$ {name}
字符串。
resources
资源的配置。资源文件通常不是代码,不需要编译,而是在项目需要捆绑使用的内容。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
- resources: 资源元素的列表,每个资源元素描述与此项目关联的文件和何处包含文件。
- targetPath: 指定从构建中放置资源集的目录结构。目标路径默认为基本目录。将要包装在 jar 中的资源的通常指定的目标路径是 META-INF。
- filtering: 值为 true 或 false。表示是否要为此资源启用过滤。请注意,该过滤器
* .properties
文件不必定义为进行过滤 - 资源还可以使用默认情况下在 POM 中定义的属性(例如$ {project.version}),并将其传递到命令行中“-D”标志(例如,“-Dname = value”)或由 properties 元素显式定义。过滤文件覆盖上面。 - directory: 值定义了资源的路径。构建的默认目录是
${basedir}/src/main/resources
。 - includes: 一组文件匹配模式,指定目录中要包括的文件,使用*作为通配符。
- excludes: 与
includes
类似,指定目录中要排除的文件,使用*作为通配符。注意:如果include
和exclude
发生冲突,maven 会以exclude
作为有效项。 - testResources:
testResources
与resources
功能类似,区别仅在于:testResources
指定的资源仅用于 test 阶段,并且其默认资源目录为:${basedir}/src/test/resources
。
plugins
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
- groupId, artifactId, version :和基本配置中的
groupId
、artifactId
、version
意义相同。 - extensions :值为 true 或 false。是否加载此插件的扩展名。默认为 false。
- inherited :值为 true 或 false。这个插件配置是否应该适用于继承自这个插件的 POM。默认值为 true。
- configuration - 这是针对个人插件的配置,这里不扩散讲解。
- dependencies :这里的
dependencies
是插件本身所需要的依赖。 - executions :需要记住的是,插件可能有多个目标。每个目标可能有一个单独的配置,甚至可能将插件的目标完全绑定到不同的阶段。执行配置插件的目标的执行。
- id: 执行目标的标识。
- goals: 像所有多元化的 POM 元素一样,它包含单个元素的列表。在这种情况下,这个执行块指定的插件目标列表。
- phase: 这是执行目标列表的阶段。这是一个非常强大的选项,允许将任何目标绑定到构建生命周期中的任何阶段,从而改变 maven 的默认行为。
- inherited: 像上面的继承元素一样,设置这个 false 会阻止 maven 将这个执行传递给它的子代。此元素仅对父 POM 有意义。
- configuration: 与上述相同,但将配置限制在此特定目标列表中,而不是插件下的所有目标。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
pluginManagement
与 dependencyManagement
很相似,在当前 POM 中仅声明插件,而不是实际引入插件。子 POM 中只配置 groupId
和 artifactId
就可以完成插件的引用,且子 POM 有权重写 pluginManagement 定义。
它的目的在于统一所有子 POM 的插件版本。
directories
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
目录元素集合存在于 build
元素中,它为整个 POM 设置了各种目录结构。由于它们在配置文件构建中不存在,所以这些不能由配置文件更改。
如果上述目录元素的值设置为绝对路径(扩展属性时),则使用该目录。否则,它是相对于基础构建目录:${basedir}
。
extensions
扩展是在此构建中使用的 artifacts 的列表。它们将被包含在运行构建的 classpath 中。它们可以启用对构建过程的扩展(例如为 Wagon 传输机制添加一个 ftp 提供程序),并使活动的插件能够对构建生命周期进行更改。简而言之,扩展是在构建期间激活的 artifacts。扩展不需要实际执行任何操作,也不包含 Mojo。因此,扩展对于指定普通插件接口的多个实现中的一个是非常好的。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
reporting
报告包含特定针对 site
生成阶段的元素。某些 maven 插件可以生成 reporting
元素下配置的报告,例如:生成 javadoc 报告。reporting
与 build
元素配置插件的能力相似。明显的区别在于:在执行块中插件目标的控制不是细粒度的,报表通过配置 reportSet
元素来精细控制。
而微妙的区别在于 reporting
元素下的 configuration
元素可以用作 build
下的 configuration
,尽管相反的情况并非如此( build
下的 configuration
不影响 reporting
元素下的 configuration
)。
另一个区别就是 plugin
下的 outputDirectory
元素。在报告的情况下,默认输出目录为 ${basedir}/target/site
。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
项目信息
项目信息相关的这部分标签都不是必要的,也就是说完全可以不填写。
它的作用仅限于描述项目的详细信息。
下面的示例是项目信息相关标签的清单:
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
这部分标签都非常简单,基本都能做到顾名思义,且都属于可有可无的标签,所以这里仅简单介绍一下:
- name - 项目完整名称
- description - 项目描述
- url - 一般为项目仓库的 host
- inceptionYear - 开发年份
- licenses - 开源协议
- organization - 项目所属组织信息
- developers - 项目开发者列表
- contributors - 项目贡献者列表, 的子标签和 的完全相同。
环境配置
issueManagement
这定义了所使用的缺陷跟踪系统(Bugzilla,TestTrack,ClearQuest 等)。虽然没有什么可以阻止插件使用这些信息的东西,但它主要用于生成项目文档。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
ciManagement
CI 构建系统配置,主要是指定通知机制以及被通知的邮箱。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
mailingLists
邮件列表
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
scm
SCM(软件配置管理,也称为源代码/控制管理或简洁的版本控制)。常见的 scm 有 svn 和 git 。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
prerequisites
POM 执行的预设条件。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
repositories
repositories
是遵循 Maven 存储库目录布局的 artifacts 集合。默认的 Maven 中央存储库位于https://repo.maven.apache.org/maven2/上。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
pluginRepositories
与 repositories
差不多。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
distributionManagement
它管理在整个构建过程中生成的 artifact 和支持文件的分布。从最后的元素开始:
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
- repository - 与
repositories
相似 - site - 站点信息
- relocation - 项目迁移位置
profiles
activation
是一个 profile
的关键。配置文件的功能来自于在某些情况下仅修改基本 POM 的功能。这些情况通过 activation
元素指定。
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
Maven工程构建
构建生命周期
Maven 构建生命周期定义了一个项目构建跟发布的过程。
一个典型的 Maven 构建(build)生命周期是由以下几个阶段的序列组成的:
阶段 | 处理 | 描述 |
---|---|---|
验证 validate | 验证项目 | 验证项目是否正确且所有必须信息是可用的 |
编译 compile | 执行编译 | 源代码编译在此阶段完成 |
测试 Test | 测试 | 使用适当的单元测试框架(例如JUnit)运行测试。 |
包装 package | 打包 | 将编译后的代码打包成可分发的格式,例如 JAR 或 WAR |
检查 verify | 检查 | 对集成测试的结果进行检查,以保证质量达标 |
安装 install | 安装 | 安装打包的项目到本地仓库,以供其他项目使用 |
部署 deploy | 部署 | 拷贝最终的工程包到远程仓库中,以共享给其他开发人员和工程 |
为了完成 default 生命周期,这些阶段(包括其他未在上面罗列的生命周期阶段)将被按顺序地执行。
Maven 有以下三个标准的生命周期:
1、Clean 生命周期:
- clean:删除目标目录中的编译输出文件。这通常是在构建之前执行的,以确保项目从一个干净的状态开始。
2、Default 生命周期(也称为 Build 生命周期):
- validate:验证项目的正确性,例如检查项目的版本是否正确。
- compile:编译项目的源代码。
- test:运行项目的单元测试。
- package:将编译后的代码打包成可分发的格式,例如 JAR 或 WAR。
- verify:对项目进行额外的检查以确保质量。
- install:将项目的构建结果安装到本地 Maven 仓库中,以供其他项目使用。
- deploy:将项目的构建结果复制到远程仓库,以供其他开发人员或团队使用。
3、Site 生命周期:
- site:生成项目文档和站点信息。
- deploy-site:将生成的站点信息发布到远程服务器,以便共享项目文档。
命令方式项目构建
命令 | 描述 |
---|---|
mvn compile | 编译项目,生成target文件 |
mvn package | 打包项目,生成jar或war文件 |
mvn clean | 清理编译或打包后的项目结构 |
mvn install | 打包后上传到maven本地仓库 |
mvn deploy | 只打包,上传到maven私服仓库 |
mvn site | 生成站点 |
mvn test | 执行测试源码 |
war包打包插件和jdk版本不匹配:pom.xml 添加以下代码即可
1 | <build> |
Clean 生命周期
当我们执行 mvn post-clean 命令时,Maven 调用 clean 生命周期,它包含以下阶段:
- pre-clean:执行一些需要在clean之前完成的工作
- clean:移除所有上一次构建生成的文件
- post-clean:执行一些需要在clean之后立刻完成的工作
mvn clean 中的 clean 就是上面的 clean,在一个生命周期中,运行某个阶段的时候,它之前的所有阶段都会被运行,也就是说,如果执行 mvn clean 将运行以下两个生命周期阶段:
1 | pre-clean, clean |
如果我们运行 mvn post-clean ,则运行以下三个生命周期阶段:
1 | pre-clean, clean, post-clean |
我们可以通过在上面的 clean 生命周期的任何阶段定义目标来修改这部分的操作行为。
例子:
1 | <project xmlns="http://maven.apache.org/POM/4.0.0" |
现在打开命令控制台,跳转到 pom.xml 所在目录,并执行下面的 mvn 命令。
1 | mvn post-clean |
Default (Build) 生命周期
这是 Maven 的主要生命周期,被用于构建应用,包括下面的 23 个阶段:
生命周期阶段 | 描述 |
---|---|
validate(校验) | 校验项目是否正确并且所有必要的信息可以完成项目的构建过程。 |
initialize(初始化) | 初始化构建状态,比如设置属性值。 |
generate-sources(生成源代码) | 生成包含在编译阶段中的任何源代码。 |
process-sources(处理源代码) | 处理源代码,比如说,过滤任意值。 |
generate-resources(生成资源文件) | 生成将会包含在项目包中的资源文件。 |
process-resources (处理资源文件) | 复制和处理资源到目标目录,为打包阶段最好准备。 |
compile(编译) | 编译项目的源代码。 |
process-classes(处理类文件) | 处理编译生成的文件,比如说对Java class文件做字节码改善优化。 |
generate-test-sources(生成测试源代码) | 生成包含在编译阶段中的任何测试源代码。 |
process-test-sources(处理测试源代码) | 处理测试源代码,比如说,过滤任意值。 |
generate-test-resources(生成测试资源文件) | 为测试创建资源文件。 |
process-test-resources(处理测试资源文件) | 复制和处理测试资源到目标目录。 |
test-compile(编译测试源码) | 编译测试源代码到测试目标目录. |
process-test-classes(处理测试类文件) | 处理测试源码编译生成的文件。 |
test(测试) | 使用合适的单元测试框架运行测试(Juint是其中之一)。 |
prepare-package(准备打包) | 在实际打包之前,执行任何的必要的操作为打包做准备。 |
package(打包) | 将编译后的代码打包成可分发格式的文件,比如JAR、WAR或者EAR文件。 |
pre-integration-test(集成测试前) | 在执行集成测试前进行必要的动作。比如说,搭建需要的环境。 |
integration-test(集成测试) | 处理和部署项目到可以运行集成测试环境中。 |
post-integration-test(集成测试后) | 在执行集成测试完成后进行必要的动作。比如说,清理集成测试环境。 |
verify (验证) | 运行任意的检查来验证项目包有效且达到质量标准。 |
install(安装) | 安装项目包到本地仓库,这样项目包可以用作其他本地项目的依赖。 |
deploy(部署) | 将最终的项目包复制到远程仓库中与其他开发者和项目共享。 |
有一些与 Maven 生命周期相关的重要概念需要说明:
当一个阶段通过 Maven 命令调用时,例如 mvn compile,只有该阶段之前以及包括该阶段在内的所有阶段会被执行。
不同的 maven 目标将根据打包的类型(JAR / WAR / EAR),被绑定到不同的 Maven 生命周期阶段。
例子(将 maven-antrun-plugin:run 目标添加到 Build 生命周期的一部分阶段中。这样我们可以显示生命周期的文本信息。)
命令行调用
在开发环境中,使用下面的命令去构建、安装工程到本地仓库
1 | mvn install |
这个命令在执行 install 阶段前,按顺序执行了 default 生命周期的阶段 (validate,compile,package,等等),我们只需要调用最后一个阶段,如这里是 install。
在构建环境中,使用下面的调用来纯净地构建和部署项目到共享仓库中
1 | mvn clean deploy |
这行命令也可以用于多模块的情况下,即包含多个子项目的项目,Maven 会在每一个子项目执行 clean 命令,然后再执行 deploy 命令。
Site 生命周期
Maven Site 插件一般用来创建新的报告文档、部署站点等。
- pre-site:执行一些需要在生成站点文档之前完成的工作
- site:生成项目的站点文档
- post-site: 执行一些需要在生成站点文档之后完成的工作,并且为部署做准备
- site-deploy:将生成的站点文档部署到特定的服务器上
这里经常用到的是site阶段和site-deploy阶段,用以生成和发布Maven站点,这可是Maven相当强大的功能,Manager比较喜欢,文档及统计数据自动生成,很好看。 在下面的例子中,我们将 maven-antrun-plugin:run 目标添加到 Site 生命周期的所有阶段中。这样我们可以显示生命周期的所有文本信息。
Maven依赖传递和依赖冲突
Maven依赖传递特性
概念
假如有Maven项目A,项目B依赖A,项目C依赖B。那么我们可以说 C依赖A。也就是说,依赖的关系为:C—>B—>A, 那么我们执行项目C时,会自动把B、A都下载导入到C项目的jar包文件夹中,这就是依赖的传递性。
作用
- 简化依赖导入过程
- 确保依赖版本正确
传递的原则
在 A 依赖 B,B 依赖 C 的前提下,C 是否能够传递到 A,取决于 B 依赖 C 时使用的依赖范围以及配置
B 依赖 C 时使用 compile 范围:可以传递
B 依赖 C 时使用 test 或 provided 范围:不能传递,所以需要这样的 jar 包时,就必须在需要的地方明确配置依赖才可以。
B 依赖 C 时,若配置了以下标签,则不能传递
1
2
3
4
5
6<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid</artifactId>
<version>1.2.15</version>
<optional>true</optional>
</dependency>
依赖传递终止
- 非compile范围进行依赖传递
- 使用optional配置终止传递
- 依赖冲突(传递的依赖已经存在)
Maven依赖冲突特性
当直接引用或者间接引用出现了相同的jar包! 这时呢,一个项目就会出现相同的重复jar包,这就算作冲突!依赖冲突避免出现重复依赖,并且终止依赖传递!
解决依赖冲突(如何选择重复依赖)方式:
自动选择原则
短路优先原则(第一原则)
A—>B—>C—>D—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
则A依赖于X(version 0.0.2)。
依赖路径长度相同情况下,则“先声明优先”(第二原则)
A—>E—>X(version 0.0.1)
A—>F—>X(version 0.0.2)
在<depencies></depencies>中,先声明的,路径相同,会优先选择!
手动排除
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15<dependency>
<groupId>com.atguigu.maven</groupId>
<artifactId>pro01-maven-java</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>compile</scope>
<!-- 使用excludes标签配置依赖的排除 -->
<exclusions>
<!-- 在exclude标签中配置一个具体的排除 -->
<exclusion>
<!-- 指定要排除的依赖的坐标(不需要写version) -->
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
</dependency>
Maven工程继承和聚合关系
Maven工程继承关系
继承概念
Maven 继承是指在 Maven 的项目中,让一个项目从另一个项目中继承配置信息的机制。继承可以让我们在多个项目中共享同一配置信息,简化项目的管理和维护工作。
继承作用
在父工程中统一管理项目中的依赖信息。
它的背景是:
- 对一个比较大型的项目进行了模块拆分。
- 一个 project 下面,创建了很多个 module。
- 每一个 module 都需要配置自己的依赖信息。
它背后的需求是:
- 在每一个 module 中各自维护各自的依赖信息很容易发生出入,不易统一管理。
- 使用同一个框架内的不同 jar 包,它们应该是同一个版本,所以整个项目中使用的框架版本需要统一。
- 使用框架时所需要的 jar 包组合(或者说依赖信息组合)需要经过长期摸索和反复调试,最终确定一个可用组合。这个耗费很大精力总结出来的方案不应该在新的项目中重新摸索。
通过在父工程中为整个项目维护依赖信息的组合既保证了整个项目使用规范、准确的 jar 包;又能够将以往的经验沉淀下来,节约时间和精力。
继承语法
父工程
1
2
3
4
5
6<groupId>com.atguigu.maven</groupId>
<artifactId>pro03-maven-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<!-- 当前工程作为父工程,它要去管理子工程,所以打包方式必须是 pom -->
<packaging>pom</packaging>
子工程
1
2
3
4
5
6
7
8
9
10
11
12
13<!-- 使用parent标签指定当前工程的父工程 -->
<parent>
<!-- 父工程的坐标 -->
<groupId>com.atguigu.maven</groupId>
<artifactId>pro03-maven-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<!-- 子工程的坐标 -->
<!-- 如果子工程坐标中的groupId和version与父工程一致,那么可以省略 -->
<!-- <groupId>com.atguigu.maven</groupId> -->
<artifactId>pro04-maven-module</artifactId>
<!-- <version>1.0-SNAPSHOT</version> -->
父工程依赖统一管理
父工程声明版本
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31<!-- 使用dependencyManagement标签配置对依赖的管理 -->
<!-- 被管理的依赖并没有真正被引入到工程 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>6.0.10</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
<version>6.0.10</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
<version>6.0.10</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
<version>6.0.10</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
<version>6.0.10</version>
</dependency>
</dependencies>
</dependencyManagement>子工程引用版本
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25<!-- 子工程引用父工程中的依赖信息时,可以把版本号去掉。 -->
<!-- 把版本号去掉就表示子工程中这个依赖的版本由父工程决定。 -->
<!-- 具体来说是由父工程的dependencyManagement来决定。 -->
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-expression</artifactId>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-aop</artifactId>
</dependency>
</dependencies>
Maven工程聚合关系
聚合概念
Maven 聚合是指将多个项目组织到一个父级项目中,以便一起构建和管理的机制。聚合可以帮助我们更好地管理一组相关的子项目,同时简化它们的构建和部署过程。
聚合作用
- 管理多个子项目:通过聚合,可以将多个子项目组织在一起,方便管理和维护。
- 构建和发布一组相关的项目:通过聚合,可以在一个命令中构建和发布多个相关的项目,简化了部署和维护工作。
- 优化构建顺序:通过聚合,可以对多个项目进行顺序控制,避免出现构建依赖混乱导致构建失败的情况。
- 统一管理依赖项:通过聚合,可以在父项目中管理公共依赖项和插件,避免重复定义。
聚合语法
父项目中包含的子项目列表。
1
2
3
4
5
6
7
8
9
10<project>
<groupId>com.example</groupId>
<artifactId>parent-project</artifactId>
<packaging>pom</packaging>
<version>1.0.0</version>
<modules>
<module>child-project1</module>
<module>child-project2</module>
</modules>
</project>聚合演示
通过触发父工程构建命令、引发所有子模块构建!产生反应堆!
IDEA中配置与使用
Idea构建Maven Java SE工程
注意:此处省略了version,直接给了一个默认值:1.0-SNAPSHOT
自己后期可以在项目中随意修改!
创建工程之后,若第一次使用maven,或者使用的是新的本地仓库,idea右下角会出现以下进度条,表示maven正在下载相关插件,等待下载完毕,进度条消失即可
验证maven工程是否创建成功,当创建完毕maven工程之后,idea中会自动打开Maven视图,如下图:
Idea构建Maven Java Web工程
手动创建
创建一个maven的javase工程
修改pom.xml文件打包方式
修改位置:项目下/pom.xml
1
2
3
4
5<groupId>com.atguigu</groupId>
<artifactId>maven_web</artifactId>
<version>1.0-SNAPSHOT</version>
<!-- 新增一列打包方式packaging -->
<packaging>war</packaging>设置web资源路径和web.xml路径
点击File–>Project Structure
刷新和校验
插件创建
安装插件JBLJavaToWeb
file / settings / plugins / marketplace
创建一个javasemaven工程
右键、使用插件快速补全web项目
参考: