1.约定的目录结构
（1）创建约定的目录结构
【1】根目录：工程名
【2】src目录：源码
【3】pom.xml文件：Maven工程的核心配置文件
【4】main目录：存放主程序
【5】test目录：存放测试目录
【6】java目录：存放Java源文件
【7】resources目录：存放框架或其他工具的配置文件
完整的目录结构如下：
(2)为什么要遵守约定的目录结构呢？
【1】Maven要·负责我们这个项目的自动化构建，以编译为例，Maven要想自动化进行编译，那么它必须知道Java源文件保存在哪里。
【2】如果我们自定义的东西想要让框架或工具知道，有两种方法：
a.以配置的方式明确告诉框架
<param-value>classpath:spring-context.xml</param-value>
b.遵守内部已经存在的约定
（3）一般情况下 约定>配置 >编码
Tips:Maven中常用的命令：
mvn clean 清理
mvn compile 编译主程序
mvn test-compile 编译测试程序
mvn test 执行测试
mvn package 打包
mvn install 安装
mvn site 生成站点
2.POM
（1）含义：Project Object Model 项目对象模型
类比：DOM ：Document Object Model 文档对象模型
（2）pom.xml对于Maven工程是核心配置文件，与构建过程相关的一切设置都是在这个文件中进行配置的，重要程度相当于web.xml对于动态Web工程的作用。
简单的pom.xml文件的示例：(下面会对里面的具体参数作介绍)
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.gs.maven</groupId>
<artifactId>WebProject2</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>jar</packaging>
</project>
3.坐标
（1）数学中的坐标：
【1】在平面上，使用X，Y两个向量可以唯一定位平面中的任何一个点
【2】在空间中，使用X，Y，Z三个向量可以唯一确定唯一的空间中的任何一个点
（2）Maven的坐标：使用下面三个向量可在仓库中唯一定位一个Maven工程（这三个向量简称为gav）
[1] groupid：公司或组织域名的倒序 + 项目名
<groupId>com.gs.maven</groupId>
[2]artifactId：模块名
<artifactId>WebProject2</artifactId>
[3]version：
<version>0.0.1-SNAPSHOT</version>
（3）Maven工程的坐标与仓库中路径的对应关系
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>4.0.0.RELEASE</version>
上面的配置文件在仓库中对应的位置为：org/springframework/spring-core/4.0.0.RELEASE/spring-core-4.0.0.RELEASE.jar
4.Maven中的仓库
（1）仓库的分类：
[1] 本地仓库：当前电脑上部署仓库的目录，为当前电脑上所有的Maven工程服务
[2] 远程仓库：
1）私服：搭建在局域网环境中，为局域网范围内所有的Maven工程服务。
2）中央仓库：架设在Internet上，为全世界所有的Maven工程服务
3）中央仓库镜像：为了分担中央仓库的流量，提升用户仓库的访问速度
（2）仓库中保存的内容：Maven工程
【1】Maven自身所需要的插件
【2】第三方框架或工具的jar包
【3】我们自己开发的Maven工程
（第一方式Jdk，第二方是我们自己）
4.依赖（核心部分）
（1）Maven解析依赖信息时会到本地仓库中查找被依赖的jar包。对于我们自己开发的Maven工程，使用mvn install命令安装后可以进入仓库。
（2）依赖的范围（也就是pom.xml中标签中三种值的范围依赖）
它的值分别为compile，test，provided
（3）依赖的传递性：
【1】好处：可以传递依赖不必在每个模块工程中重复声明，在“最下面”的工程中依赖异常即可
【2】注意：非compile范围的依赖不能传递，所以在每个工程模块中，如果有需要就得重复声明依赖。
（4）依赖的排除
【1】需要设置依赖排除的场合：确实需要的依赖中由于传递性导入了不稳定的jar包
【2】依赖排除的设置：（代码示例）
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
（5）依赖的原则：
【1】作用：解决模块工程之间的jar包冲突
【2】情景设定1：验证路径最短者优先原则
【3】情景设定2：路径相同时先声明者优先
先声明者指的是标签内声明的顺序
（6）统一管理依赖的版本
【1】情景举例：如果对spring各个jar包的依赖要从4.0.0 统一升级到4.1.1，怎么办？手动逐一修改并不可靠
【2】建议配置方式：
a.在标签内使用自定义标签统一声明版本号
<properties>
<gs.spring.version>4.1.1.RELEASE</gs.spring.version>
</properties>
b.在需要统一版本的位置，使用${自定义标签名}引用声明的版本号
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>${gs.spring.version}</version>
<scope>compile</scope>
【3】其实标签配合自定义标签声明的数据配置并不是只能用于声明依赖的版本号，凡是需要统一声明后再引用的场合都可以使用。
5.生命周期/插件/目标
（1）生命周期
【1】各个构建环节执行的顺序：不能打乱顺序，必须按照既定的正确顺序来执行
【2】Maven的核心程序中定义了抽象的生命周期，周期中各个阶段的具体任务都是由插件来完成的。
【3】Maven核心程序为了更好的实现自动化构建，按照这样的特点执行生命周期中的各个阶段，不论现在需要执行生命周期的哪一个阶段，都是从这个生命周期的最初位置开始执行。
(2)插件和目標
【1】生命周期中的各个阶段仅仅定义了要执行的任务是什么
【2】各个阶段和插件的目标是对应的
【3】相似的目标由特定的插件来完成
【4】可以将目标看作“调用插件”功能的命令。
6.继承
（1）场景：由于test范围的依赖不能传递，所以必然分散在各个模块工程中，很容易造成版本不一致（例如不同模块中依赖不同的junit版本）
（2）需求：统一管理各个模块中对junit依赖的版本
（3）解决思路：将junit依赖统一提取到“父”工程中，在子工程中声明junit依赖是不指定版本，以父工程中统一设定为准，同时便于修改。
（4）操作步骤：
【1】创建一个Maven工程作为父工程，注意打包方式为pom
【2】在子工程中声明对父工程的引用
【3】将子工程的坐标与父工程中重复的内容删除
【4】在父工程中统一管理junit的依赖（pom.xml的配置如下）
<!-- 配置依赖的管理 -->
<dependencyManagement>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.9</version>
<scope>test</scope>
</dependency>
</dependencies>
</dependencyManagement>
【5】在子工程中删除junit依赖的版本号部分
Tips:配置继承后，执行安装命令时要先安装父工程
7.聚合
（1）作用：一键安装各个模块工程
（2）配置方式：在一个总的聚合工程中配置个参与聚合的模块（一般习惯使用父工程）
<!-- 配置聚合 -->
<modules>
<!-- 指定子工程的相对路径 -->
<module>../Hello</module>
<module>../HelloFriend</module>
<module>../MakeFriend</module>
</modules>
（3）使用方式：在聚合工程的pom.xml上右键—>run as ---->mvn install
