Maven是Java世界中一个很好使的项目管理工具，关于【好使】这个特性从项目的使用量上就能体现出来，虽然说现在有更好使的Gradle，但是Maven的地位也不会那么轻易被撼动，支持者还是多多。
Maven的产生背景
在学习一个新知识之前，应该要以历史的眼光来看待这个技术出现的原因，以及这个技术解决的问题，也就是背景，这样能更好地理解这个技术。
在没有Maven之前，开发一个项目，当需要用到别人写的代码的时候，基本上是这样的：
1.开发一个项目，当需要用到别人写好的jar包，就需要把开源的jar包下载下来放到项目的lib目录下，并且根据这个目录添加到CLASSPATH中，以此来告诉Java执行环境，在哪些目录下可以找到要执行的Java程序需要的类或者包。
2.当下载了aa.jar包之后，发现还需要依赖bb.jar包，于是就去下载bb.jar包，重复步骤直到下载并添加完所有需要的jar包。
3.如果运气好，项目在添加完所有的依赖之后就能够正常运行了。但是如果运气差的话，就会遇到版本的问题，比如aa.jar包在调用bb.jar包的时候发现bb.jar包中根本没有需要的方法，这个方法只存在在bb.jar包别的版本中，那么这样的话，就需要花不少的时间在查找依赖和适配版本的jar包上了。
4.另外的，往git或者svn上提交代码的时候，还必须要把这些lib都上传上去，否则别人就要重复你前面做过的所有查找和添加依赖的操作。同样的，别人下载你的代码也是要把完整的lib下载下来。这样，不仅会浪费代码版本管理的时间，代码版本管理的空间，还会提高的开发的时间成本和降低开发的效率。
这时候Maven作为Java世界中的包管理工具就应运而生。就好像Linux世界中的yum、Web前端世界中的webpack一样，是一种方便开发者管理各种依赖的包管理工具。
Maven仓库的种类
Maven查找jar包的过程是这样的：先在本地仓库找；找不到的话，就去私服找（如果配置了私服的话）；再找不到，就到中央仓库去找（默认的中央仓库是http://repo1.maven.org/maven2/，由Maven团队负责维护）。
最后如果在中央仓库找到之后，就会在私服和本地仓库都放一份，从私服找到之后也会在本地仓库放一份，这样下次再查找依赖就不需要到中央仓库去下载了。
关于仓库的配置，当你安装（Windows下一般是解压和配置环境变量）好了Maven之后，Maven的安装目录在conf目录下会有一个settings.xml配置文件，这个配置文件中提供了很多的配置项，其中就有配置仓库的配置项，包括本地仓库、私服和中央仓库的配置。
关于私服首先要搭建私服，比较繁琐，需要用另外的篇幅来记录，因此这里就略过私服的配置，只提及本地仓库和中央仓库的配置。
本地仓库的配置是通过localRepository标签配置的：
<!-- localRepository | The path to the local repository maven will use to store artifacts. | | Default: ${user.home}/.m2/repository --> <localRepository>D:maven_repo</localRepository>
中央仓库的配置是通过mirrors-mirror标签配置的（这里设置为淘宝镜像）：
<mirrors> <!-- mirror | Specifies a repository mirror site to use instead of a given repository. The repository that | this mirror serves has an ID that matches the mirrorOf element of this mirror. IDs are used | for inheritance and direct lookup purposes, and must be unique across the set of mirrors. | <mirror> <id>mirrorId</id> <mirrorOf>repositoryId</mirrorOf> <name>Human Readable Name for this Mirror.</name> <url>http://my.repository.com/repo/path</url> </mirror> --> <mirror> <id>nexus-aliyun</id> <mirrorOf>central</mirrorOf> <name>Nexus aliyun</name> <url>http://maven.aliyun.com/nexus/content/groups/public</url> </mirror> </mirrors>
需要注意的是，这些配置项如果不进行配置的话，Maven是提供有默认值的，默认值都在注释掉的配置项中。
在自身的属性配置这一点上，Maven都贯彻了【约定优于配置】的理念，真的是优秀啊。
Maven项目的整体结构
Maven遵循的原则是【约定优于配置】，因此使用Maven构建的项目的默认结构是下图这样的：
1.Maven默认配置了${project.basedir}/src/main/java为项目的源代码目录。
2.Maven默认配置了${project.basedir}/src/main/test为项目的测试代码目录。
3.Maven默认配置了${project.basedir}/target为项目的编译输出目录等。
。。。
当然了，既然说是默认配置，当然是可以修改的，可以在项目的pom.xml的build标签中修改这些源代码目录，只是一般不建议改，一般人也不会去改。
<build> <sourceDirectory>src/java</sourceDirectory> <testSourceDirectory>src/test</testSourceDirectory> <outputDirectory>output/classes</outputDirectory> <testOutputDirectory>output/test-classes</testOutputDirectory> <directory>target/jar</directory> </build>
Maven项目结构的特殊性是由【约定优于配置】的特性来决定的，这一特性减少了很多不必要的配置，是使之打败前辈Ant的主要原因之一。
Maven管理工具的目录结构
下图是Maven管理工具的目录结构。
bin目录：该目录包含了mvn运行的脚本，这些脚本用来配置Java命令，准备好CLASSPATH和相关的Java系统属性，然后执行Java命令。
boot目录：该目录只包含一个文件，该文件为plexus-classworlds-2.5.2.jar。plexus-classworlds是一个类加载器框架，相对于默认的Java类加载器，它提供了更加丰富的语法以方便配置，Maven使用该框架加载自己的类库。
conf目录：该目录包含了一个非常重要的文件settings.xml。直接修改该文件，就能在机器上全局地定制Maven的行为，即对所有用户都生效。一般情况下，我们更偏向于复制该文件至~/.m2/目录下，然后修改该文件，在用户级别定制Maven的行为。
lib目录：该目录包含了所有Maven运行时需要的Java类库，Maven本身是分模块开发的，因此用户能看到诸如maven-core-3.0.jar、maven-model-3.0.jar之类的文件，此外这里还包含一些Maven用到的第三方依赖如commons-cli-1.2.jar、commons-lang-2.6.jar等等。
settings.xml配置文件
这里详细说一下settings.xml这个文件，这个文件用于定制Maven的行为。上面已经说到settings.xml可以放在2个位置，一个是【~/.m2/setting.xml】（默认没有，需要我们自己复制），一个是【${maven.home}/conf/setting.xml】。这2个位置的配置文件的加载顺序为【~/.m2/setting.xml】>【${maven.home}/conf/setting.xml】，为了不影响他人，所以我们将conf下的settings.xml复制到用户目录，在用户级别定制Maven的行为。
这个和系统配置环境变量有点类似，Windos和Linux都可以配置系统级别的环境变量和用户级别的环境变量，用户级别的环境变量会覆盖系统级别的环境变量。
Maven的一些常用命令
要使用Maven当然要会一些常用的命令，不然都不叫会使用Maven。
| 命令 | 描述 |
|---|---|
| mvn -version | 显示版本信息 |
| mvn clean | 删除target目录 |
| mvn compile | 编译src/main/java下的源代码 |
| mvn package | 打包，在target下生成jar包或者war包 |
| mvn test | 执行src/test/java下以Test开头或者以Test结尾的类的测试用例 |
| mvn install | 打包，并把jar包或者war包复制到本地仓库，供其他模块使用 |
| mvn deploy | 将打包的文件发布到私服 |
| mvn dependency:tree | 打印出项目的整个依赖树 |
当然也可以将命令连着使用，比如使用【mvn clean package】清理打包；比如使用【mvn clean package -DskipTests=true】清理打包，并跳过测试用例；比如使用【mvn clean install】清理打包，并将jar包或者war包复制到本地仓库。
更多的，也可以配合将结果输出到文件来方便查看，比如【mvn dependency:tree > dependency.txt】。
pom.xml中的<dependency>标签
<dependency>标签中一般是包含<groupId>、<artifactId>和<version>三个子标签。
<groupId>表示公司域名倒过来，<artifactId>表示功能的命名，<version>表示版本号，这三个维度就确定了一个jar包，就像用(x, y, z)坐标在三维空间中确定一个唯一的点一样。
另外的，<dependency>标签中还可以包含<scope>标签，表示此依赖包的作用范围，下面列出一个<scope>参数候选值的表格。
| 参数 | 解释 | 是否会被打入最终的jar包 |
|---|---|---|
| compile | 默认的scope（不指定） | 是 |
| test | 测试使用 | 否 |
| provided | 编译需要 | 否 |
| runtime | 编译不需要，运行时需要（接口与实现分离） | 是 |
| system | 加载本地jar（很少使用） | 否 |
"长得丑的水果，都会努力让自己甜一点。"