使用 Maven：命令行环境

使用 Maven：命令行环境

---

根据坐标创建 Maven 工程

使用三个『向量』在『Maven的仓库』中唯一的定位到一个『jar』包。

向量：组织名称.项目名称.版本号

1. groupId：公司或组织的 id
2. artifactId：一个项目或者是项目中的一个模块的 id
3. version：版本号

例如：

groupId：com.abc.maven

artifactId：pro01-abc-maven

version：1.0-SNAPSHOT

jar包和存储路径关系

pom.xml代码中

对应本地位置

---

Maven核心概念：POM

POM：Project Object Model，项目对象模型

将工程抽象为一个模型，再用程序中的对象来描述这个模型。体现在 Maven 工程根目录下 pom.xml 这个配置文件

Maven约定的目录结构

还有一个target目录存放构建输出的结果。

Maven 为了让构建过程能够尽可能自动化完成，所以必须约定目录结构的作用。

例如：Maven 执行编译操作，必须先去 Java 源程序目录读取 Java 源代码，然后执行编译，最后把编译结果存放在 target 目录。

---

执行Maven 命令

mvn clean

删除 target 目录

mvn compile

主程序编译

mvn test-compile

测试程序编译

主体程序编译结果存放的目录：target/classes

测试程序编译结果存放的目录：target/test-classes

mvn package

打包成jar包，存放target文件夹

mvn install

将本地构建过程中生成的 jar 包存入 Maven 本地仓库，根据它的坐标生成。

---

测试依赖范围

导入jar包后，<scope></scope>范围

标签的可选值：compile/test/provided/system/runtime/import

结论:

  compile：实际运行时真正要用到的 jar 包都是以 compile 范围进行依赖的。

  test：测试过程中使用的 jar 包，以 test 范围依赖进来。比如 junit。

  provided：在开发过程中需要用到的“服务器上的 jar 包”通常以 provided 范围依赖进来。这个范围的 jar 包之所以不参与部署、不放进 war 包，就是避免和服务器上已有的同类 jar 包产生冲突，同时减轻服务器的负担。说白了就是：“服务器上已经有了，你就别带啦！”

---

依赖的传递性

在 A 依赖 B，B 依赖 C 的前提下，C 是否能够传递到 A，取决于 B 依赖 C 使用compile范围才可以传递

test和provided范围不能传递

---

依赖的排除

当 A 依赖 B，B 依赖 C 而且 C 可以传递到 A 的时候，

A 不想要 C，需要在 A 里面把 C 排除掉。

这种情况都是为了避免 jar 包之间的冲突。

---

项目继承

A项目继承B项目

B父项目，A子项目

本质上是 A 工程的 pom.xml 中的配置继承了 B 工程中 pom.xml 的配置

这样可以使每一个模块module统一管理jar包，是整个项目统一。