maven系列目标：从入门开始开始掌握一个高级开发所需要的maven技能。

这是maven系列第1篇。

为什么我们要学习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平台的项目构建和依赖管理。

下篇我们将介绍maven的使用。