为什么我们要学习 maven?
学习某些技术，肯定是我们遇到了某些问题，而这些问题目前手头上没有很好的方案去解决，此时刚好有一种技术可以很好的解决这个问题，这样能够驱动我们愿意去学。所以我们学任何技术之前，需要先了解这种技术能够解决什么问题。带着问题去学习，大家才有兴趣，才能够更快的掌握。
我们遇到了什么问题呢？
maven 还未出世的时候，我们有很多痛苦的经历。
痛点1：jar 包难以寻找
比如我们项目中需要用到 fastjson，此时我们会去百度上检索 fastjson 相关 jar 包，然后下载下来，放到项目的 lib 下面，然后加到项目的 classpath 下面，用着用着发现这个 jar 的版本太老了，不是我们想要的，然后又重新去找，痛苦啊。
痛点2：jar 包依赖的问题
jar 包一般都不是独立存在的，一般一些 jar 也会用到其他的 jar，比如 spring-aop.jar 会用到 spring-core.jar，这种依赖可能比较简单，有些依赖可能有很多级，比如 a.jar 依赖于 b.jar，而 b.jar 依赖c.jar，而c.jar 又依赖于 b.jar，当你用到 a.jar 的时候，你需要把其他3个也进入才可以，所以你用到一个 jar 的时候，你必须明确知道这些 jar 还会依赖于哪些 jar，把他们都引入进来，否则项目是无法正常运行的，当项目用到很多 jar 的时候，我们是很难判断缺少哪些 jar 的，只有在项目运行过程报错了，才知道，这种也是相当痛苦的，浪费了大量时间。
痛点3：jar 包版本冲突问题
项目中用到了 a.jar，a.jar 依赖于 c.jar 的1.5版本，然后我们把这2个 jar 拷贝到项目中，后面又用到了b.jar，但是 b.jar 又依赖于 c.jar 的1.0版本，此时你把 b.jar 和 c-1.0.jar 引进来了，会发现 c.jar 有2个版本，发生冲突了，启动的时候会报错，这种情况你要着手去解决 jar 冲突的问题，也是非常痛苦的。
当我们从网上找到一个 jar 包来使用的时候，我们是很难判断这个 jar 依赖的其他 jar 的版本的，比如 a.jar 依赖于 b.jar，你从网上把 b.jar 找到了，最后放入项目中，发现 b.jar 的版本太老了，又得去重新找。
记得之前在第三方支付工作的时候，我记忆犹新，当时用到的是 lvy 来引入 jar 的，这玩意解决 jar 包的冲突没有什么好办法，为了解决项目中 jar 包冲突的问题，花了整整一周时间。
痛点4：jar 包不方便管理
当我们的项目比较大的时候，我们会将一个大的项目分成很多小的项目，每个小项目由几个开发负责，比如一个电商项目分为：账户相关的项目、订单相关的项目、商品相关的项目，这些项目的结构都是类似的，用到的技术都是一样的：ssm（spring、springmvc、mybatis），然后每个项目都需要把这些 jar 拷贝一份到自己的项目目录中，最后10个项目只是 jar 就复制了10份，后来，我们发现项目中有些 jar 需要升级版本，打算替换一下，此时我们需要依次去替换10个项目，也是相当痛苦。
痛点5：项目结构五花八门
很久之前，我们使用 eclipse 搭建一个项目的时候，java 源码的位置、资源文件的位置、测试文件的位置、静态资源位置、编译之后的 class 文件位置，都是可以随意放的，这些是由各自公司的架构师搭建项目时定好的，根据他们的经验来定义的，导致每个公司可能项目结构都不太一样，来新人之后，看到项目结构一脸闷逼，根本不知道哪是哪，需要人指导，无形的增加了成本，如果大家都按照某种规范采用同一种项目结构，这样岂不是很方便么，大家按照某种约定，项目使用同样的结构，比如：java 文件、资源文件、测试用例、静态资源、编译之后的 class、打包之后 jar 的位置等等各种文件的位置，这些东西，如果所有做 java 开发的公司都约定好的，这样拿到一个项目之后，就可以省去很多事情了。
痛点6：项目的生命周期控制方式五花八门
一个项目对于开发来说，生命周期是这样的：搭建项目结构、编码、跑测试用例、编译、打包、发布到环境测试、发布到生产环境。其中除了编码之外，大多数时间都是在编译、打包、发布到测试环境，然后测试开始测试，测试提出 bug，开发接着修改 bug，之后又进行自测、编译、打包、发布到测试环境，多数时间都在重复着跑单元测试、编译、打包、发布的工作。在没有自动化编译的时候，每个过程都需要我们手动去操作，可能有些开发比较优秀，将这些操作写出自动化的脚本来进行了，但是每个人写的自动化的脚本可能都是不一样的，有些用 java 写，有些人用 shell 写等等。
后面有了 Ant，ant 可以将运行测试用例、编译、打包、发布搞成自动化的，ant 自由度比较高，需要自己去写很多配置，比如编译：需要指定源码位于什么地方，编译之后的文件放在什么地方。ant 的灵活度比极高，细节都交给了开发者自己去控制了，每个人写出来的 ant 脚本也是各种各样的，不利于大家统一维护和接受。
像上面这些过程，几乎是所有 java 项目都需要经历的，属于高频必备的操作，如果全世界所有开发 java 的能够约定好 java 项目的结构，测试用例存放的位置，编译之后的 class 存放的位置、打包之后文件存放的位置，自动化脚本都是用同一种规范来开发，那么大家最终写的自动化发布的脚本都是类似的，只是最后发布的地址不一样，其他都是一样的，这样的脚本会简化很多，新人来了上手也非常快。
maven 是什么
maven 就是解决上面所有痛点的神器，算是所有开发者的福音。
使用 maven 搭建的项目架构，都需要遵循同样的结构，java 源文件、资源文件、测试用例类文件、静态资源文件这些都是约定好的，大家都按照这个约定来，所有如果你们的项目是使用 maven 创建的，招新人来接手，如果他们懂 maven，根本不需要培训，上来就可以看懂整个项目的结构。
maven 给每个 jar 定义了唯一的标志，这个在 maven 中叫做项目的坐标，通过这个坐标可以找到你需要用到的任何版本的 jar 包。
maven 会自动解决 jar 依赖的问题，比如你用到了 a-1.0.jar，而 a-1.0.jar 依赖于 b-1.1.jar 和 c-1.5.jar，当我们通过 maven 把 a-1.0.jar 引入之后，b-1.1.jar 和 c-1.5.jar 会自动被引入进来。
maven 可以很容易的解决不同版本之间的 jar 冲突的问题。
maven 使开发者更加方便的控制整个项目的生命周期，比如：
mvn clear 可以清理上次已编译好的代码
mvn compile 可以自动编译项目
mvn test 可以自动运行所有测试用例
mvn package 可以完成打包需要的所有操作(自动包含了清理、编译、测试的过程)
还有更多更多好用的操作，由于 maven 使所有项目结构都是约定好的，所以这些操作都被简化为了非常简单的命令。
我们自己开发了一些工具包，需要给其他人使用时，只需要一个简单的 mvn install 命令就可以公布出去了，然后将这个 jar 的坐标告知使用者，使用者就可以找到了，根本不需要你将 jar 包传输给他。
由于 maven 项目结构都是约定好的，所以非常方便扩展，上面说的各种 maven 命令都是以插件的形式集成进来的，如果你愿意，你也可以自己开发一些 maven 插件给其他人使用，比如阿里内部自己开发的插件自动将项目发布到阿里云上面，非常方便开发发布项目。
再来看一下官方解释什么是 maven：maven 是 apache 软件基金会组织维护的一款自动化构建工具，专注服务于 java 平台的项目构建和依赖管理。
-- end --