标签：直接 project 专注 依赖关系 操作 verify 主程序 repos 多模块
1.添加第三方jar包
2.解决jar包之间的依赖关系
3.获取第三方jar包
4.将项目拆成多个工程模块
是Apache软件基金会组织维护的一款自动化构建工具，专注服务于 Java 平台的项目构建和依赖管理。
1.清理：删除以前的编译结果，为重新编译做好准备。
2.编译：将 Java 源程序便以为字节码文件。
3.测试：针对项目中的关键点进行测试，确保项目在迭代开发过程中关键点的正确性。
4.报告：在每一次测试后以标准的格式记录和展示测试结果
5.打包：将一个包含诸多文件的工程封装为一个压缩文件用于安装或部署。Java 工程对应 jar 包，Web 工程对应 war 包。
6.安装：在 Maven 环境下特指将打包的结果—— jar 包或 war 包安装到本地仓库。
7.部署：将打包的结果部署到远程仓库或将 war 包部署到服务器上运行。
1.POM
2.约定的目录结构
3.坐标
4.依赖管理
5.仓库管理
6.生命周期
7.插件和目标
8.继承
9.聚合
Maven 的核心程序中仅仅定义了抽象的声明周期，具体的操作是由 Maven 的插件完成的。Maven 的插件不包含在 Maven 的核心程序中，在首次使用时需要联网下载。
下载的插件被保存在本地仓库，本地仓库的默认位置是：~\.m2\repository
约定的目录结构对于 Maven 实现自动化构建是必不可缺的一环，Maven 必须能找到 Java 源文件，编译后的字节码也有一个存储的位置，所以约定至关重要。
目录结构：
项目
src
main
java
resources
test
java
resources
targetsrc：源码目录
main：主程序目录
main->java：主程序的Java源文件目录
main->resources：主程序的资源文件目录
test：测试程序目录
test->java：测试程序的Java源文件目录
test->resources：测试程序的资源文件目录
Project Object Model：项目对象模型。将 Java 工程的相关信息封装为对象作为便于操作和管理的模型。Maven 工程的核心配置。可以说学习 Maven 就是学习 pom.xml 文件中的配置。
在空间中需要 x、y、z三个向量确定一个点
使用如下三个向量在 Maven 的仓库中唯一的确定一个 Maven 工程(gav)。
1.groupid：公司或组织的域名倒叙+当前项目名称
2.artifactid：当前项目的模块名称
3.version：当前模块的版本
<groupId>com.jikedaquan.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>使用命令 mvn install 执行安装后 Maven 工程进入仓库，通过两个步骤查找 jar 包。
1.将 gav 三个向量连起来
com.jikedaquan.maven+Hello+0.0.1-SNAPSHOT2.以连起来的的字符串作为目录结构到仓库中查找
com/jikedaquan/maven/Hello/0.0.1-SNAPSHOT/Hello-0.0.1-SNAPSHOT.jar使用 Maven 就是为了使用它的依赖功能，当 A jar 包用到了 B jar 包的某些类时，A 对 B 产生了依赖。
实现依赖：
<dependency>
<groupId>com.jikedaquan.maven</groupId>
<artifactId>Hello</artifactId>
<version>0.0.1-SNAPSHOT</version>
<scope>compile</scope>
</dependency>依赖的范围有：compile(编译)、test(测试)、provided(部署)
| 作用 | compile | test | provided |
|---|---|---|---|
| 主程序 | √ | × | √ |
| 测试程序 | √ | √ | × |
| 参与部署 | √ | × | × |
依赖的传递：A 依赖 B，B 依赖 C ，A 是否能使用 C？要看 B 依赖 C 的范围是不是 compile
依赖的排除：
<dependencies>
<dependency>
<groupId>com.jikedaquan</groupId>
<artifactId>c</artifactId>
<version>1.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>对版本号进行统一：
1.统一声明版本号
<properties>
<mysql-connector.version>5.1.47</mysql-connector.version>
</properties>2.引用前面声明的版本号：
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysql-connector.version}</version>
</dependency>仓库有本地仓库和远程仓库，远程仓库包含私服、中央仓库、中央仓库的镜像。
仓库中存储的文件有 Maven 的插件、我们自己开发的项目的模块、第三方框架或工具的 jar 包。
Maven 生命周期定义了各个构建缓解的执行顺序，有了这个清单，Maven 就可以自动化的执行构建命令了。
有3套相互独立的生命周期，分别是：
Clean Lifecycle 在进行真正的构建之前进行的一些清理工具。
Default Lifecycle 构建的核心部分，编译，测试，打包，安装部署等等。
Site Lifecycle 生成项目报告，站点，发布站点
它们是相互独立的，你可以仅仅调用 clean 来清理工作目录，仅仅调用 site 来生成站点。也可以直接运行 mvn clean install site 运行所有这三套声明周期
Clean 生命周期的阶段：
pre-clean 执行一些需要在 clean 之前完成的工作
clean 移除所有上一次构建生成的文件
post-clean 执行一些需要在 clean 之后立刻完成的工作
Site 生命周期的阶段：
Default 生命周期的阶段
Default 生命周期是 Maven 生命周期中最重要的一个，绝大部分工作都发生在这个生命周期中。这里，只解释一些比较重要和常用的阶段：
validate
generate-sources
process-sources
generate-resources
process-resources 复制并处理资源文件，至目标目录，准备打包
compile 编译项目的源代码
process-classes
generate-test-sources
process-test-sources
generate-test-resources
process-test-resources 复制并处理资源文件，至目标测试目录
test-compile 编译测试源代码
process-test-classes
test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署
prepare-package
package 接受编译好的代码，打包成可发布的格式，如 JAR
pre-integration-test
integration-test
verify
install 将包安装至本地仓库，以让其他项目依赖
deploy 将最终的包复制到远程的仓库，以让其他开发人员与项目共享或部署到服务器上运行
运行任何一个阶段的时候，它前面的所有阶段都会被运行
Maven 的核心仅仅定义了抽象的声明周期，具体的任务都是交给插件完成的。
每个插件都能实现多个功能，每个功能就是一个插件目标
Maven 的声明周期与插件目标相互绑定，以完成某个具体的构建任务
非 compile 范文的依赖信息是不能在“依赖链”中传递的，所以有需要的工程只能单独配置。
| 工程 | 依赖 |
|---|---|
| Hello | <dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.0</version><scope>test</scope></dependency> |
| HelloFriend | <dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.0</version><scope>test</scope></dependency> |
| MakeFriend | <dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>4.0</version><scope>test</scope></dependency> |
如果将各模块的版本统一为 4.9，各个模块单独修改是不可取的，可以使用继承机制将依赖信息统一提取到父工程模块中进行统一管理。
1.创建父工程：打包方式设置为 pom
2.在子工程中已用父工程
<parent>
<!-- 父工程坐标 -->
<groupId>...</groupId>
<artifactId>...</artifactId>
<version>...</version>
<relativePath>从当前目录到父项目的 pom.xml文件的相对路径</relativePath>
</parent>如果此时子工程的 groupId 和 version 和父工程重复则可以删除
3.在父工程中管理依赖
将 Parent 项目中的 dependencies 标签，用 dependencyManagement 标签括起来
<dependencyManagement>
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
</dependencies>
</dependencyManagement>在子项目中重新制定需要的依赖，删除范围和版本号
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
</dependency>
</dependencies>将多个工程拆分为模块后，需要手动逐个安装到仓库后依赖才能够生效。修改源码后也需药逐个手动进行 clean 操作。而使用了聚合之后就可以批量进行 Maven 工程的安装、清理工作。
配置聚合：
在总的聚合工程中使用 modules/module 标签组合，指定模块工程的相对路径集合
<modules>
<module>test</module>
<module>b</module>
</modules>我们可以到 http://mvnrepository.com/搜索需要的 jar 包的依赖信息。
搜索关注公众号「享智同行」，第一时间获取技术干货
标签：直接 project 专注 依赖关系 操作 verify 主程序 repos 多模块
原文地址：https://www.cnblogs.com/AIThink/p/9768758.html
