Maven 是 Apache 下的一个纯 Java 开发的开源项目。基于项目对象模型（缩写：POM）概念，Maven利用一个中央信息片断能管理一个项目的构建、报告和文档等步骤。它是一个项目管理工具，可以对 Java 项目进行构建、依赖管理。
约定
Maven 使用约定优于配置的原则，提倡使用一个共同的标准目录结构。
在了解这些之前，我都一直认为 ${basedir}/src/main/java 是java项目的既有约定，而非maven的约定大于配置。
| 目录 | 作用 |
|---|---|
| ${basedir} | 存放pom.xml和所有的子目录 |
| ${basedir}/src/main/java | 项目的java源代码 |
| ${basedir}/src/main/resources | 项目的资源，比如说property文件，springmvc.xml，application.yml |
| ${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默认的本地仓库目录位置 |
插件
Maven 有以下三个标准的生命周期：
- clean：项目清理的处理
- default(或 build)：项目部署的处理
- site：项目站点文档创建的处理 每个生命周期中都包含着一系列的阶段(phase)。这些 phase 就相当于 Maven 提供的统一的接口，然后这些 phase 的实现由 Maven 的插件来完成。
我们在输入 mvn 命令的时候 比如 mvn clean，clean 对应的就是 Clean 生命周期中的 clean 阶段， clean 的具体操作是由 maven-clean-plugin 来实现的。
Maven 实际上是一个依赖插件执行的框架，每个任务实际上是由插件完成。在默认情况下，Maven 会绑定默认插件来完成基本操作。
| plugin | function | life cycle phase |
|---|---|---|
| maven-clean-plugin | 清理上一次执行创建的目标文件 | clean |
| maven-resources-plugin | 处理源资源文件和测试资源文件 | resources,testResources |
| maven-compiler-plugin | 编译源文件和测试源文件 | compile,testCompile |
| maven-surefire-plugin | 执行测试文件 | test |
| maven-jar-plugin | 创建 jar | jar |
| maven-install-plugin | 安装 jar，将创建生成的 jar 拷贝到 .m2/repository 下面 | install |
| maven-deploy-plugin | 发布 jar | deploy |
如果针对各个 plugin 有特殊配置的话，需要显示指定 plugin 和 属性配置。例如，bulid
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
仓库
Maven 仓库是项目中依赖的第三方库，这个库所在的位置叫做仓库。
Maven 仓库有三种类型：
- 本地（local）
- 中央（central）
- 远程（remote）
本地仓库，在安装 Maven 后并不会创建，它是在第一次执行 maven 命令的时候才被创建。Maven 本地仓库默认被创建在 %USER_HOME% 目录下。要修改默认位置，在 %M2_HOME%\conf 目录中的 Maven 的 settings.xml 文件中定义另一个路径。
中央仓库，是由 Maven 社区提供的仓库，其中包含了大量常用的库。中央仓库包含了绝大多数流行的开源Java构件，以及源码、作者信息、SCM、信息、许可证信息等。
远程仓库，它是开发人员自己定制仓库，包含了所需要的代码库或者其他工程中用到的 jar 文件。
Maven 依赖搜索顺序
当我们执行 Maven 构建命令时，Maven 开始按照以下顺序查找依赖的库：
- 步骤 1 － 在本地仓库中搜索，如果找不到，执行步骤 2，如果找到了则执行其他操作。
- 步骤 2 － 在中央仓库中搜索，如果找不到，并且有一个或多个远程仓库已经设置，则执行步骤 4，如果找到了则下载到本地仓库中以备将来引用。
- 步骤 3 － 如果远程仓库没有被设置，Maven 将简单的停滞处理并抛出错误（无法找到依赖的文件）。
- 步骤 4 － 在一个或多个远程仓库中搜索依赖的文件，如果找到则下载到本地仓库以备将来引用，否则 Maven 将停止处理并抛出错误（无法找到依赖的文件）。
关于配置远程仓库
在pom.xml中使用repositories标签来配置maven项目的远程仓库。例如：
<repositories>
<repository>
<id>alimaven</id>
<name>aliyun maven</name>
<url>http://maven.aliyun.com/nexus/content/groups/public/</url>
<releases>
<!-- 可以从这个仓库下载releases版本的构件-->
<enabled>true</enabled>
</releases>
<snapshots>
<!-- 不要从这个仓库下载snapshot版本的构件-->
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
关于版本号
菜鸟网站关于maven版本的一则评论：
1、Snapshot 版本代表不稳定、尚处于开发中的版本。
2、Release 版本则代表稳定的版本。
3、什么情况下该用 SNAPSHOT?
协同开发时，如果 A 依赖构件 B，由于 B 会更新，B 应该使用 SNAPSHOT 来标识自己。这种做法的必要性可以反证如下：
a. 如果 B 不用 SNAPSHOT，而是每次更新后都使用一个稳定的版本，那版本号就会升得太快，每天一升甚至每个小时一升，这就是对版本号的滥用。 b.如果 B 不用 SNAPSHOT, 但一直使用一个单一的 Release 版本号，那当 B 更新后，A 可能并不会接受到更新。因为 A 所使用的 repository 一般不会频繁更新 release 版本的缓存（即本地 repository)，所以B以不换版本号的方式更新后，A在拿B时发现本地已有这个版本，就不会去远程Repository下载最新的 B
4、 不用 Release 版本，在所有地方都用 SNAPSHOT 版本行不行？
不行。正式环境中不得使用 snapshot 版本的库。 比如说，今天你依赖某个 snapshot 版本的第三方库成功构建了自己的应用，明天再构建时可能就会失败，因为今晚第三方可能已经更新了它的 snapshot 库。你再次构建时，Maven 会去远程 repository 下载 snapshot 的最新版本，你构建时用的库就是新的 jar 文件了，这时正确性就很难保证了。
