第一章 Maven简介

###1.1 何为Maven###  Maven的中文意思是“专家”、“内行”。作为Apache组织的一个颇为成功的开源项目，Maven主要服务于基于Java平台的项目构建，依赖管理和项目信息管理。 #### 1.1.1 什么是构建####  软件开发过程中编写源代码之外的编译、运行单元测试、生成文档、打包和部署就是构建。如果手工完成这一系列的操作那成本太高了，于是有人用软件的方法让一系列的工作完全自动化，使得构建的工作可以像自动化流水线一样只需要一条简单的命令。 #### 1.1.2 Maven是一个优秀的构建工具####  Maven作为一个构建工具，不仅能帮我们自动化构建，还能够抽象构建过程，提供构建任务实现；它跨平台，提供对外一致的操作接口，这一切足以使它成为优秀的流行的构建工具。 #### 1.1.3 Maven不仅仅是构建工具####  Maven不仅是构建工具，还是一个依赖管理工具和项目信息管理工具。它提供了中央仓库，能够自动下载构建。

###1.2. 为什么需要Maven### #### 1.2.1 组装PC和品牌PC####  使用脚本构建高度自定义的构建系统就像组装PC，耗时费力结果也不一定好。使用Maven就像购买品牌PC，省时省力，并能得到成熟的构建系统，Maven还是开源的能够得到Maven社区的帮助。 #### 1.2.2 IDE不是万能的####  我们应该合理的使用IDE而不是过多的依赖它。使用IDE构建需要一次次的点击鼠标，手动操作意味着效率低和容易出错。Maven是这方面的专家，而且主流的IDE都集成了Maven，我们可以在IDE中使用Maven方便的执行构建。 #### 1.2.3 Make####  Make也许是最早的构建工具，它由Stuart Feldman于1977年在Bell实验室创建。目前Make有很多衍生版本，包括流行的GUN Make和BSD Make以及Windows平台的Microsoft nmake等。
 Make由一个名为Makefile的脚本文件驱动，该文件使用Make自定义的语言格式。其基本组成规则为一些列规格(rules)，而每一条规格又包括目标、依赖和命令。
 Make通过一系列目标和依赖将整个构建过程串联起来，同时利用本地命令完成每个目标的实际行为。Make的强大之处在于它可以所有系统的本地命令。但是，Make将自己和操作系统绑定在一起了，也就是说Make就不能实现（至少很难）跨平台的构建，这对于Java来说是很不友好的。此外，Makefile的语法也成为问题，很多人抱怨Make构建失败的原因往往就是一个难以发现的空格或者Tab使用错误。 #### 1.2.4 Ant####  它最早用来构建著名的Tomcat，创建它的动机就是受不了Makefile的语法格式。可以将Ant看作是一个Java版本的Ant，正因为使用了Java，Ant是跨平台的。此外，Ant用XML定义构建脚本，更加友好。
 和Make一样Ant也是过程式的，开发者显示的制定一个目标以及完成此目标所需要执行的任务。针对每一个项目，开发者都需要重新编写这一过程，这里包含着很大的重复。Ant是没有依赖管理的，所以很长一段时间内Ant都不得不手工管理依赖。 #### 1.2.5 不重复发明轮子####  小张是一家小型民营软件公司的程序员，他所在的公司要开发一个新的Web项目。经过协商，决定使用Spring、iBatis和Tapstry。jar包去哪里找呢？公司里估计没有人能把Spring、iBatis和Tapstry所使用的jar包一个不少地找出来。大家的做法是，先到Spring的站点上去找一个spring.with.dependencies，然后去iBatis的网站上把所有列出来的jar包下载下来，对Tapstry、Apache commons等执行同样的操作。项目还没有开始，WEB.INF/lib下已经有近百个jar包了，带版本号的、不带版本号的、有用的、没用的、相冲突的，怎一个“乱”字了得！
 在项目开发过程中，小张不时地发现版本错误和版本冲突问题，他只能硬着头皮逐一解决。项目开发到一半，经理发现最终部署的应用的体积实在太大了，要求小张去掉一些没用的jar包，于是小张只能加班加点地一个个删……
 小张隐隐地觉得这些依赖需要一个框架或者系统来进行管理。
 小张喜欢学习流行的技术，前几年Ant十分流行，他学了，并成为了公司这方面的专家。小张知道，Ant打包，无非就是创建目录，复制文件，编译源代码，使用一堆任务，如copydir、fileset、classpath、ref、target，然后再jar、zip、war，打包就成功了。
 项目经理发话了：“兄弟们，新项目来了，小张，你来写Ant脚本！”
 “是，保证完成任务！”接着，小张继续创建一个新的XML文件。targetclean; target compile; target jar; …… 不知道他是否想过，在他写的这么多的Ant脚本中，有多少是重复劳动，有多少代码会在一个又一个项目中重现。既然都差不多，有些甚至完全相同，为什么每次都要重新编写？
 终于有一天，小张意识到了这个问题，想复用Ant脚本，于是在开会时他说：“以后就都用我这个规范的Ant脚本吧，新的项目只要遵循我定义的目录结构就可以了。”经理听后觉得很有道理：“嗯，确实是个进步。”
这时新来的研究生发言了：“经理，用Maven吧，这个在开源社区很流行，比Ant更方便。”小张一听很惊讶，Maven真比自己的“规范化Ant”强大？其实他不知道自己只是在重新发明轮子，Maven已经有一大把现成的插件，全世界都在用，你自己不用写任何代码！
 为什么没有人说“我自己写的代码最灵活，所以我不用Spring，我自己实现IoC；我不用Hibernate，我自己封装JDBC”？ ###1.3. Maven与极限编程(XP)###  极限编程是敏捷开发的一种，极限编程是一个轻量级的、灵巧的软件开发方法；同时它也是一个非常严谨和周密的方法。它的基础和价值观是交流、朴素、反馈和勇气；即，任何一个软件项目都可以从四个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。
 极限编程（XP）是近些年在软件行业红得发紫的敏捷开发方法，它强调拥抱变化。该软件开发方法的创始人Kent Beck提出了XP所追求的价值、实施原则和推荐实践。下面看一下Maven是如何适应XP的。
 首先看一下Maven如何帮助XP团队实现一些核心价值：

• 简单。
   Maven暴露了一组一致、简洁的操作接口，能帮助团队成员从原来的高度自定义的、复杂的构建系统中解脱出来，使用Maven现有的成熟的、稳定的组件也能简化构建系统的复杂度。
• 交流与反馈。  与版本控制系统结合后，所有人都能执行最新的构建并快速得到反馈。此外，自动生成的项目报告也能帮助成员了解项目的状态，促进团队的交流。

 此外，Maven更能无缝地支持或者融入到一些主要的XP实践中：

• 测试驱动开发（TDD）。
   TDD强调测试先行，所有产品都应该由测试用例覆盖。而测试是Maven生命周期的最重要的组成部分之一，并且Maven有现成的成熟插件支持业界流行的测试框架，如JUnit和TestNG。
• 十分钟构建。
   十分钟构建强调我们能够随时快速地从源码构建出最终的产品。这正是Maven所擅长的，只需要一些配置，之后用一条简单的命令就能让Maven帮你清理、编译、测试、打包、部署，然后得到最终的产品。
• 持续集成（CI）。
   CI强调项目以很短的周期（如15分钟）集成最新的代码。实际上,CI的前提是源码管理系统和构建系统。目前业界流行的CI服务器如Hudson和CruiseControl都能很好地和Maven进行集成。也就是说，使用Maven后，持续集成会变得更加方便。
• 富有信息的工作区。
   这条实践强调开发者能够快速方便地了解到项目的最新状态。当然，Maven并不会帮你把测试覆盖率报告贴到墙上，也不会在你的工作台上放个鸭子告诉你构建失败了。不过使用Maven发布的项目报告站点，并配置你需要的项目报告，如测试覆盖率报告，都能帮你把信息推送到开发者眼前。
   上述这些实践并非只在XP中适用。事实上，除了其他敏捷开发方法如SCRUM之外，几乎任何软件开发方法都能借鉴这些实践。也就是说，Maven几乎能够很好地支持任何软件开发方法。
   例如，在传统的瀑布模型开发中，项目依次要经历需求开发、分析、设计、编码、测试和集成发布阶段。从设计和编码阶段开始，就可以使用Maven来建立项目的构建系统。在设计阶段，也完全可以针对设计开发测试用例，然后再编写代码来满足这些测试用例。然而，有了自动化构建系统，我们可以节省很多手动的测试时间。此外，尽早地使用构建系统集成团队的代码，对项目也是百利而无一害。最后，Maven还能帮助我们快速地发布项目。

转载于:https://my.oschina.net/u/1415012/blog/505421