我为什么使用maven

　　上周五我想添加一个验证码的功能,打算使用jcaptcha框架.从网上找了很久的jar包,结果无非是用不了,或者已损坏,或者要积分.
　　心态爆炸.把有限的精力花在无意义的寻找上,逐渐掏空身体.
　　我花了一天学会了使用mvn,很快就从无尽的搜索中解脱了.mvn定义依赖的方式非常简单,pom文件中定义三坐标,就能轻松get到需要的jar.
　　但是使用者快就可以发现,mvn带来的红利并不仅仅在于此.随便使用其中几个功能,都能体会到他设计的强大之处.
　　这里只是介绍mvn的强大之处,并不是使用教程.网上资料非常详尽,就不必浪费篇幅了.如果想体验各种用法,请移步mvn-in-action
　　
　　1 依赖
　　先说依赖管理.这个是mvn带来的第一个最直观的福利.
　　这部分的思路非常简单,建立中央仓库,提供统一xml编写规则,提供下载.关于语法不必多说,有更多的语法介绍博客,就不贴了.但是如果mvn的依赖管理只是一个下载工具的话,就完全小看了他.
　　
　　1.1  依赖范围和传递依赖
　　mvn中scope属性值得一说,这表明mvn所声明的依赖是可以存在其中的一些部分的.换句话说,你可以让这个依赖仅仅在编译的时候产生作用,也可以在测试时产生作用.因为并不是所有的依赖都需要参与到构建的各个生命周期中.如果没声明,那么默认compile.
　　然后要说传递依赖,如果你声明了一个依赖,叫a.jar.但是a.jar又依赖b.jar.声明了a的依赖,是不是也需要声明b依赖.当有很多的依赖链的时候呢?mvn会通过解析pom文件,将a.jar的依赖,也就是b.jar也引入到项目中.不需动手,就能隐式引入所需要的jar,是不是美滋滋.
　　但是这又会引发一个问题,假设a -> b -> d 又存在 a -> b -> c -> d.我们只声明了a,最后肯定也需要d,那么我们走那条线?肯定是走近的.
　　因为我们a是我们需要的,bd或者bcd是a需要的,假设我们只需要a能够为我们所用就可以,c这个东西反正也不会用,那a到底通过哪条依赖链并不重要,当然越短越好.三长一短选最短.
　　但是如果一样长呢? 选先声明的那个.
　　事情其实还没有这么简单就结束了.万一这个依赖是可选的呢?比如说 a -> b -> m,又有 a ->b ->n. m,n都是可选的,所以就是不必要的,于是mvn就走到必要的b就结束了.
　　但是项目中的实现需要m,就不能指望让这个链去帮开发者去找,那么就需要自己显示声明m.所以说,自己写的是最安心的.
　　那么写到这里回头一想,不是自己写的是不是就会有风险?假设 a -> b -> c,我们只声明了a,项目中其实也是需要这个c,但是这个链是mvn控制的,c.jar是mvn找的.如果说有一天c升到了一个快照版,那么这个项目是不是就有风险,或者又引起蛋疼的版本问题呢.所以,maven提供了新的解决方法,就是显示声明c,写好版本号.有显示声明的就不会去通过链找.
　　mvn提供了依赖树可以让开发者更清晰的优化依赖.清除不必要的,显示声明必要的.
　　
　　废了这么多话,就是说,如果你需要依赖一个包,就去显式声明,这样最安全.如果你不确定是不是依赖了这个包,或者说写多余了,这不有依赖树嘛.
　　最后,传递依赖还会受到依赖范围的影响.网上有图有表.就不贴了.
　　
　　1.2仓库
　　mvn为开发者提供了中央仓库,每个开发者都可以通过丰富的中央仓库找到自己所需要的jar.然后下载到本地.
　　setting.xml文件我也不介绍了.这里主要是强调两点.
　　第一个是我们可以通过搭建私服减少团队的下载压力,而且也可以很方便的发布自己的jar到私服.有时这是值得的.搭建私服的工具很多,nexus等等,网上都有教程.
　　第二个是我们比对本地仓库地址和中央仓库的地址映射关系.你会发现其中的相似之处.
　　
　　2  构建
　　然后熟悉mvn的指令之后,我们很快就能体验到mvn带来的第二个显而易见的福利.构建
　　可能很多开发者不去编写自己的单元测试代码,可能很多开发者并不参与到编译部署的环节中,所以对整个项目的很多过程并不是很了解.但是一旦你使用ant去构建项目,你会发现不同的项目,不同的环境,可能会带来不同的配置方式.手动意味着低效,失败率.所以mvn提供了自己简单的命令行,就可以集开发,测试,集成,打包,部署为一个标准而优雅的流程.每个部分只需要一行命令就可以搞定,无视不同项目,不同环境带来的差异.更不用去进行各色的配置了.
　　但是这一切并不是没有代价,这要求项目的编写要按照mvn的规则去编写.按照mvn设定的结构,才能使用mvn简单的语句.学习mvn的项目结构很简单,做一点小小的改变可以减少那么多构建的复杂流程,这是非常值得的.惯例优于配置,只要开发者做过几套构建过程,就会感激mvn为此简化做出的贡献.
　　mvn尽管使用了有自己特色的项目结构,但并不代表打包或者编译时就有什么特殊之处.举例说,在src/main/resources目录下的配置文件,在运行时候是会放到web-inf目录下的class中以提供classpath的.所以不必意外.
　　
　　2.1生命周期
　　构建也是分步骤的.有clean,default和site.三套生命周期.我说这个的意思是,不要把mvn clean install认为是一个指令,这是调用了两个生命周期的两个阶段.
　　
　　2.2 插件机制
　　但是mvn是如何通过简单的指令完成的编译工作?假设你对mvn的其中一个构建流程有自己的要求,可不可以自定义一些功能进去,或者干脆自己提供这一部分的实现.mvn满足你.
　　mvn是通过插件的方式去完成各个生命周期的指令的.如果细心的去研究build标签下的一些插件,你会发现规律.mvn内置绑定了自己的插件,所以开发者在输入指令的时候是轻松而且愉快的.如果你有自己的特殊需求,尽可以去plugins中做自己的修改.
　　所以可以预见的是,我们可以在命令行中直接配置插件信息,或者干脆在pom配置中直接改变configuration.比如非常常用的跳过测试的 mvn -install -Dmavenue.test.skip=true,也可以在pom的插件中配置相应的地方为true.
　　结合 2.1 2.2,生命周期的步骤实现都是和插件紧密相连的.
　　
　　2.3 部署站点
　　生命周期还提到了site,我认为可能很多人不会用到.mvn给开发者提供了部署站点的功能,教程略.可以说是非常贴心了.虽然很多独立开发者甚至团队开发可能不会做站点部署吧.
　　如果有兴趣,可以试着搭一下,非常简单,也很有趣.
　　
　　3.测试
　　其实测试真的没必要大书特书.但是基于太多人多单元测试的忽略,我觉得还是有必要一提.
　　mvn提供了单元测试.只要你的测试类是Test开头或者Test或者TrestCase结尾,都会被mvn识别并进行测试.并生成报告.当然也可以对特定模块进行测试.
　　操作是非常简单,但是很多人对此视而不见.可以说,一个好的单元测试节省了太多时间.我见到太多人修改了service的方法之后,不得不重新打开网页,新建一条数据,然后各种操作.
　　单元测试,拥有可信赖的测试数据,屏蔽其他环节带来的干扰,避免因为一个bug而在整条线上翻来服务寻找.
　　单元测试,拥有固定的测试用例,即使过了一年两年,依然可以轻松的敲定这个环节没有问题,确信代码的质量,而不用重新回忆如何重现当年操作.
　　可能编写单元测试比较痛苦,浪费时间,但是长远来看,这是高效的.而且,只有编写单元测试代码,才有自动化单元测试的可能.
　　我是肯定不愿意tdd,这有些本末倒置,但是单元测试非常有用.
　　
　　4.聚合和继承
　　1.聚合
　　当一个项目下面有多个模块的时候,开发者当然希望能够出现一个总的模块,来进行统一的mvn构建.没有问题,mvn允许开发者建立一个模块,去聚合开发者想聚合的模块,从而进行统一的构建过程.
　　
　　2.继承
　　当有了一个父类的时候,下面的子类就一定想把各自中相同的部分上交到父类中.
　　按照这个思路,我们可以预见,假设这个项目中所有的模块都依赖了spring-framework这个包,那么写到父模块的pom中不就可以了吗?如果开发者希望各个模块的版本保持一致,是不是也可以在父模块中声明类似常量的东西直接引用呢?是的,如果你已经习惯继承带来的好处,在mvn中也能找到相似之处.
　　
　　3.构建顺序
　　如果开发者的项目有十个模块,那么再构建过程中,构建优先顺序是什么?
　　具体理论就不摆了,我些不太清楚.如果你学过数据结构的图,你应该更容易想象其中的情景.
　　写到这我突然想起拼图游戏.拼图我会怎么拼,我会先拼最边缘的部分,为什么?因为最边缘的没有依赖谁,我不管别的放的对不对,在边角的那块拼图一定会放在那里,谁也不会影响他.所以构建的优先顺序是,先找最边缘的,也就是谁都不依赖的模块构建,接下来以这些模块为基础,在往上找.
　　如果两个模块互相依赖呢?这就说明你依赖方式有问题,mvn会报错提示.如果这个过程你想有一个装逼点的说法,它叫反应堆.
　　
　　5.其他
　　mvn中的细节还有很多,mvn甚至也可以进行项目的版本管理.我觉得对于本文的目的已经足够了.
　　学习是肯定要有学习成本的,所以在学之前,肯定也有必要研究一下是否需要学习,减少自己的无用功.比如ejb就的学习价值就很低了,知识无穷,时间有限,我们还是选一些有趣的事情去做.
　　我为什么使用mvn?因为mvn在依赖上处理的非常出色,因为mvn的构建十分简洁,对项目的结构的搭建相对清晰.
　　想一想我们用maven构建项目,也可以结合 Jenkins进行项目持续集成,cargo进行自动化部署.是不是可以省下一点时间,喝杯茶,看看天呢.

　　最后一点.mvn的所有细节我都看过了,很多部分也实践了,的确被吸引.但是想想一开始的初衷,是因为没有网站积分才会想起使用mvn
　　贫穷,使我好学 .  /doge