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的使用。