Maven实战读书笔记

Maven实战读书笔记

什么是构建

编译、 运行 单元 测试、 生成 文档、 打包 和 部署 等过程称之为构建。

pom.xml

Maven 项目 的 核心 是 pom. xml。 POM（ Project Object Model， 项目 对象 模型） 定义 了 项目 的 基本 信息， 用于 描述 项目 如何 构建， 声明 项目 依赖

groupId、 artifactId 和 version

groupId、 artifactId 和 version 的 三行。 这 三个 元素 定义 了 一个 项目 基本 的 坐标， 在 Maven 的 世界， 任何 的 jar、 pom 或者 war 都是 以 基于 这些 基本 的 坐标 进行 区分 的。

这里有点有意思的就是当你有一个自己或者别人编写的jar，可是你并不知道它的组织信息和版本号什么，当你想把他将它安装到你本地仓库的时候，groupId和artifactId和version都是可以自己定义的，只要你在pom里面保持一致就能将jar引入到你的项目中。

groupId 定义 了 项目 属于 哪个 组， 这个 组 往往 和 项目 所在 的 组织 或 公司 存在 关联。

artifactId 定义 了 当前 Maven 项目 在 组 中 唯一 的 ID，

version 指定了版本

快照

如1. 0- SNAPSHOT。 SNAPSHOT 意为 快照， 说明 该 项目 还 处于 开发 中， 是 不稳定的版本。

如果依赖中存在快照版本的jar，每次构建的时候，会自动检测仓库中是否有新的快照版本

比如 模块 A 的 版本 设定 为 2. 1- SNAPSHOT，在 发布 的 过程中， Maven 会 自动 为 构件 打上 时间 戳。 比如 2. 1- 20191214. 221414- 13 就 表示 2019 年 12 月 14 日 22 点 14 分 14 秒 的 第 13 次 快照。 有了 该 时间 戳， Maven 就能 随时 找到 仓库 中 该 构件 2. 1- SNAPSHOT 版本 最新 的 文件。

maven所有的命令都是基于插件的，当我们执行第一条maven命令的时候会去下载插件到我们的本地maven仓库中

clean

告诉 Maven 清理 输出 目录 target/

compile

compile 任务， 将 项目 主 代码 编译 至 target/ classes 目录

mvn clean compile

clean 告诉 Maven 清理 输出 目录 target/， compile 告诉 Maven 编译 项目 主 代码， 从 输出 中 看到 Maven 首先 执行 了 clean： clean 任务， 删除 target/ 目录。 默认 情况下， Maven 构建 的 所有 输出 都在 target/ 目录 中； 接着 执行 resources： resources 任务（ 未定义 项目 资源， 暂且 略过）； 最后 执行 compiler： compile 任务， 将 项目 主 代码 编译 至 target/ classes 目录。

scope

scope 为 依赖 范围， 若 依赖 范围 为 test 则 表示 该 依赖 只对 测试 有效。 换句话说， 测试 代码 中的 import JUnit 代码 是 没有 问题 的， 但是 如果 在 主 代码 中用 import JUnit 代码， 就会 造成 编译 错误。 如果不 声明 依赖 范围， 那么 默认值 就是 compile， 表示 该 依赖 对 主 代码 和 测试 代码 都 有效。

·compile： 编译 依赖 范围。 如果 没有 指定， 就会 默认 使用 该 依赖 范围。 使用 此 依赖 范围 的 Maven 依赖， 对于 编译、 测试、 运行 三种 classpath 都 有效。 典型的 例子 是 spring- core， 在 编译、 测试 和 运行 的 时候 都 需要 使用 该 依赖。

·test： 测试 依赖 范围。 使用 此 依赖 范围 的 Maven 依赖， 只对 于 测试 classpath 有效， 在 编译 主 代码 或者 运行 项目 的 使用 时 将 无法 使用 此类 依赖。 典型的 例子 是 JUnit， 它 只有 在编 译 测试 代码 及 运行 测试 的 时候 才 需要。

·provided： 已提 供 依赖 范围。 使用 此 依赖 范围 的 Maven 依赖， 对于 编译 和 测试 classpath 有效， 但在 运行时 无效。 典型的 例子 是 servlet- api， 编译 和 测试 项目 的 时候 需要 该 依赖， 但在 运行 项目 的 时候， 由于 容器 已经 提供， 就不 需要 Maven 重复 地 引入 一遍。

·runtime： 运行时 依赖 范围。 使用 此 依赖 范围 的 Maven 依赖， 对于 测试 和 运行 classpath 有效， 但在 编译 主 代码 时 无效。 典型的 例子 是 JDBC 驱动 实现， 项目 主 代码 的 编译 只需 要 JDK 提供 的 JDBC 接口， 只有 在 执行 测试 或者 运行 项目 的 时候 才 需要 实现 上述 接口 的 具体 JDBC 驱动。

·system： 系统 依赖 范围。

·import（ Maven 2. 0. 9 及 以上）： 导入 依赖 范围。

mvn clean test

可以用来自动执行测试代码

mvn clean package

用来打包，默认是jar，在pom中可以指定，至于打出来包的名字也是可以指定的。可以通过finalName用来指定名字

fileName

用来指定打包的名字

install

将 项目 输出 的 jar 安装 到了 Maven 本地 仓库 中

mvn clean install

执行 test 之前 是 会 先 执行 compile 的， 执行 package 之前 是 会 先 执行 test 的， 而 类似 地， install 之前 会 执行 package，总结：mvn clean package实际执行了 compiler，test，package，install。

何为 Maven 坐标

Maven 定义 了 这样 一组 规则： 世界上 任何 一个 构件 都可以 使用 Maven 坐标 唯一 标识， Maven 坐标 的 元素 包括 groupId、 artifactId、 version、 packaging、 classifier。 现在， 只要 我们 提供 正确 的 坐标 元素， Maven 就能 找到 对应 的 构件。

groupId、 artifactId、 version 是 必须 定义 的， packaging 是 可选 的（ 默认 为 jar）， 而 classifier 是 不能 直接 定义 的。

packaging

该 元素 定义 Maven 项目 的 打包 方式。

传递性依赖：

B依赖A,C依赖B，那么C也可以使用A的依赖

传递性 依赖 机制， Maven 会 解析 各个 直接 依赖 的 POM， 将那 些 必要 的 间接 依赖， 以 传递性 依赖 的 形式 引入 到 当前 的 项目 中。

传递性依赖范围：最左边为第一依赖，最上面为第二依赖

如：A依赖B范围是test，则B称为第一依赖，而B又要依赖C范围是compile，那么C称为第二依赖,则C对于A来说依赖范围是test

第一声明优先

依赖传递会导致版本混乱， 但是 从 Maven 2. 0. 9 开始， 为了 尽可能 避免 构建 的 不确定性， Maven 定义 了 依赖 调解 的 第二 原则： 第一 声明者 优先。路径长短来判断。如关系： A-> B-> C-> X（ 1. 0）、 A-> D-> X（ 2. 0），此时会有两个x，实际使用的是2.0那个，因为路径短。

exclusions

为什么需要排除依赖：

使传递性 依赖 会 给 项目 隐式 地 引入 很多 依赖， 这 极大 地 简化 了 项目 依赖 的 管理， 但是 有些 时候 这种 特性 也会 带来 问题。 例如， 当前 项目 有一个 第三方 依赖， 而 这个 第三方 依赖 由于 某些 原因 依赖 了 另外 一个 类 库 的 SNAPSHOT 版本， 那么 这个 SNAPSHOT 就会 成为 当前 项目 的 传递性 依赖， 而 SNAPSHOT 的 不稳定 性 会 直接影响 到 当前 的 项目。 这时 就 需要 排 除掉 该 SNAPSHOT， 并且 在当 前项 目中 声明 该类 库 的 某个 正式 发布 的 版本。 还有 一些 情况， 你 可能 也 想要 替换 某个 传递性 依赖， 比如 Sun JTA API， Hibernate 依赖于 这个 JAR， 但是 由于 版权 的 因素， 该类 库 不在 中央 仓库 中， 而 Apache Geronimo 项目 有一个 对应 的 实现。 这时 你就 可以 排除 Sun JAT API， 再 声明 Geronimo 的 JTA API 实现，

用 exclusions 元素 声明 排除 依赖， exclusions 可以 包含 一个 或者 多个 exclusion 子 元素， 因此 可以 排除 一个 或者 多个 传递性 依赖。 需要 注意 的 是， 声明 exclusion 的 时候 只需 要 groupId 和 artifactId， 而 不需要 version 元素，

maven仓库

得益 于 坐标 机制， 任何 Maven 项目 使用 任何 一个 构件 的 方式 都是 完全 相同 的。 在此 基础上， Maven 可以 在某 个位 置 统一 存储 所有 Maven 项目 共享 的 构件， 这个 统一 的 位置 就是 仓库。 实际 的 Maven 项目 将不 再 各自 存储 其 依赖 文件， 它们 只需 要 声明 这些 依赖 的 坐标， 在 需要 的 时候（ 例如， 编译 项目 的 时候 需要 将 依赖 加入 到 classpath 中）， Maven 会 自动 根据 坐标 找到 仓库 中的 构件， 并使 用 它们。

maven默认查找路径

本地-私服-远程仓库

生命周期

Maven 的 生命 周期 就是 为了 对 所有 的 构建 过程 进行 抽象 和 统一。 Maven 从 大量 项目 和 构建 工具 中 学习 和 反思， 然后 总结 了 一套 高度 完善 的、 易 扩展 的 生命 周期。 这个 生命 周期 包含 了 项目 的 清理、 初始化、 编译、 测试、 打包、 集成 测试、 验证、 部署 和 站点 生成 等 几乎 所有 构建 步骤。

Maven拥有三套独立的生命周期：

它们 分别为 clean、 default 和 site。 clean 生命 周期 的 目的 是 清理 项目， default 生命 周期 的 目的 是 构建 项目， 而 site 生命 周期 的 目的 是 建立 项目 站点。

clean 生命周期

1） pre- clean 执行 一些 清理 前 需要 完成 的 工作。

2） clean 清理 上一次 构建 生成 的 文件。

3） post- clean 执行 一些 清理 后 需要 完成 的 工作。

default 生命周期

default 生命 周期 定义 了 真正 构建 时 所需 要 执行 的 所有 步骤， 它是 所有 生命 周期 中最 核心 的 部分。像compile，test，package，install都是发生在这个时期内

site 生命周期

site 生命 周期 的 目的 是 建立 和 发布 项目 站点， Maven 能够 基于 POM 所 包含 的 信息， 自动 生成 一个 友好 的 站点， 方便 团队 交流 和 发布 项目 信息。

常见POM元素含义解释

·groupId： 项目 组 ID， 项目 坐标 的 核心 元素。

·version： 项目 版本， 项目 坐标 的 核心 元素。

·description： 项目 的 描述 信息。

·organization： 项目 的 组织 信息。

·inceptionYear： 项目 的 创始 年份。

·url： 项目 的 URL 地址。

·developers： 项目 的 开发者 信息。

·contributors： 项目 的 贡献者 信息。

·distributionManagement： 项目 的 部署 配置。

·issueManagement： 项目 的 缺陷 跟踪 系统 信息。

·ciManagement： 项目 的 持续 集成 系统 信息。

·scm： 项目 的 版本 控制系统 信息。

·mailingLists： 项目 的 邮件 列表 信息。

·properties： 自定义 的 Maven 属性。

·dependencies： 项目 的 依赖 配置。

·dependencyManagement： 项目 的 依赖 管理 配置。（常见于多模块项目中，用于锁定版本，子模块中仍需要引入具体依赖）

·repositories： 项目 的 仓库 配置。

·build： 包括 项 目的 源 码 目录 配置、 输出 目录 配置、 插件 配置、 插件 管理 配置 等。

·reporting： 包括 项目 的 报告 输出 目录 配置、 报告 插件 配置 等。