搜索
Maven权威指南 来源: ‐book/reference_zh/public‐book.html Authors Tim O'Brien (Sonatype, Inc.) , John Casey (Sonatype, Inc.) , Brian Fox (Sonatype, Inc.) , Bruce Snyder () , Jason VanZyl (Sonatype, Inc.) , Juven Xu () Chapter1.介绍ApacheMaven1.1.Maven...它是什么?1.2.约定优于配置（ConventionOverConfiguration）1.3.一个一般的接口1.4.基于Maven插件的全局性重用1.5.一个“项目”的概念模型1.6.Maven是Ant的另一种选择么？1.7.比较Maven和Ant1.8.总结虽然网络上有许多Maven的参考文章，但是没有一篇单独的，编写规范的介绍Maven的文字，它需要是一本细心编排的入门指南和参考手册。我们做的，正是试图提供这样的，包含许多使用参考的文字。1.1.Maven...它是什么?如何回答这个问题要看你怎么看这个问题。绝大部分Maven用户都称Maven是一个构建工具：一个用来把源代码构建成可发布的构件的工具。构建工程师和项目经理会说Maven是一个更复杂的东西：一个项目管理工具。那么区别是什么？像Ant这样的构建工具仅仅是关注预处理，编译，打包，测试和分发。像Maven这样的一个项目管理工具提供了构建工具所提供功能的超集。除了提供构建的功能，Maven还可以生成报告，生成Web站点，并且帮助推动工作团队成员间的交流。一个更正式的ApacheMaven的定义：Maven是一个项目管理工具，它包含了一个项目对象模型(ProjectObjectModel)，一组标准集合，一个项目生命周期(ProjectLifecycle)，一个依赖管理系统(DependencyManagementSystem)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。当你使用Maven的时候，你用一个明确定义的项目对象模型来描述你的项目，然后Maven可以应用横切的逻辑，这些逻辑来自一组共享的（或者自定义的）插件。别让Maven是一个项目管理工具的事实吓跑你。如果你只是在找一个构建工具，Maven能做这个工作。事实上，本书的一些章节将会涉及使用Maven来构建和分发你的项目。1.2.约定优于配置（ConventionOverConfiguration）约定优于配置是一个简单的概念。系统，类库，框架应该假定合理的默认值，而非要求提供不必要的配置。流行的框架如RubyonRails和EJB3已经开始坚持这些原则，以对像原始的EJB2.1规范那样的框架的配置复杂度做出反应。一个约定优于配置的例子就像EJB3持久化，将一个特殊的Bean持久化，你所需要做的只是将这个类标注为@Entity。框架将会假定表名和列名是基于类名和属性名。系统也提供了一些钩子，当有需要的时候你可以重写这些名字，但是，在大部分情况下，你会发现使用框架提供的默认值会让你的项目运行的更快。Maven通过给项目提供明智的默认行为来融合这个概念。在没有自定义的情况下，源代码假定是在${basedir}/src/main/java，资源文件假定是在${basedir}/src/main/resources。测试代码假定是在${basedir}/src/test。项目假定会产生一个JAR文件。Maven假定你想要把编译好的字节码放到${basedir}/target/classes并且在${basedir}/target创建一个可分发的JAR文件。虽然这看起来无关紧要，但是想想大部分基于Ant的构建必须为每个子项目定义这些目录。Maven对约定优于配置的应用不仅仅是简单的目录位置，Maven的核心插件使用了一组通用的约定，以用来编译源代码，打包可分发的构件，生成web站点，还有许多其他的过程。Maven的力量来自它的武断，它有一个定义好的生命周期和一组知道如何构建和装配软件的通用插件。如果你遵循这些约定，Maven只需要几乎为零的工作——仅仅是将你的源代码放到正确的目录，Maven将会帮你处理剩下的事情。使用“遵循约定优于配置”系统的一个副作用是用户可能会觉得他们被强迫使用一种特殊的方法。当然Maven有一些核心观点不应该被怀疑，但是其实很多默认行为还是可配置的。例如项目源码的资源文件的位置可以被自定义，JAR文件的名字可以被自定义，在开发自定义插件的时候，几乎任何行为可以被裁剪以满足你特定的环境需求。如果你不想遵循约定，Maven也会允许你自定义默认值来适应你的需求。1.3.一个一般的接口在Maven为构建软件提供一个一般的接口之前，每个单独的项目都专门有人来管理一个完全自定义的构建系统。开发人员必须在开发软件之外去学习每个他们要参与的新项目的构建系统的特点。在2001年，构建一个项目如Turbine和构建另外一个项目如Tomcat，两者方法是完全不同的。如果一个新的进行静态源码分析的源码分析工具面世了，或者如果有人开发了一个新的单元测试框架，每个人都必须放下手头的工作去想办法使这个新东西适应每个项目的自定义构建环境。如何运行单元测试？世界上有一千种不同的答案。构建环境由无数无休止的关于工具和构建程序的争论所描述刻画。Maven之前的时代是低效率的时代，是“构建工程师”的时代。现在，大部分开源开发者已经或者正在使用Maven来管理他们新的软件项目。这种转变不仅仅是开发人员从一种构建工具转移到另外一种构建工具，更是开发人员开始为他们的项目采用一种一般的接口。随着软件系统变得越来越模块化，构建系统变得更复杂，而项目的数量更是如火箭般飞速上升。在Maven之前，当你想要从Subversion签出一个项目如ApacheActiveMQ或ApacheServiceMix，然后从源码进行构建，你需要为每个项目留出一个小时来理解给它的构建系统。这个项目需要构建什么？需要现在什么类库？把类库放哪里？构建中我该运行什么目标？昀好的情况下，理解一个新项目的构建需要几分钟，昀坏的情况下（例如Jakarta项目的旧的ServletAPI实现），一个项目的构建特别的困难，以至于花了几个小时以后，新的贡献者也只能编辑源码和编译项目。现在，你只要签出源码，然后运行：mvninstall。虽然Maven有很多优点，包括依赖管理和通过插件重用一般的构建逻辑，但它成功的昀核心原因是它定义了构建软件的一般的接口。每当你看到一个使用Maven的项目如ApacheWicket，你就可以假设你能签出它的源码然后使用mvninstall构建它，没什么好争论的。你知道点火开关在哪里，你知道油门在右边，刹车在左边。1.4.基于Maven插件的全局性重用Maven的核心其实不做什么实际的事情，除了解析一些XML文档，管理生命周期与插件之外，它什么也不懂。Maven被设计成将主要的职责委派给一组Maven插件，这些插件可以影响Maven生命周期，提供对目标的访问。绝大多数Maven的动作发生于Maven插件的目标，如编译源码，打包二进制代码，发布站点和其它构建任务。你从Apache下载的Maven不知道如何打包WAR文件，也不知道如何运行单元测试，Maven大部分的智能是由插件实现的，而插件从Maven仓库获得。事实上，第一次你用全新的Maven安装运行诸如mvninstall命令的时候，它会从中央Maven仓库下载大部分核心Maven插件。这不仅仅是一个昀小化Maven分发包大小的技巧，这种方式更能让你升级插件以给你项目的构建提高能力。Maven从远程仓库获取依赖和插件的这一事实允许了构建逻辑的全局性重用。MavenSurefire插件是负责运行单元测试的插件。从版本1.0发展到目前广泛使用的在JUnit基础上增加了TestNG测试框架支持的版本。这种发展并没有破坏向后兼容性，如果你使用之前Surefire插件编译运行你的JUnit3单元测试，然后你升级到了昀新版本的Surefire插件，你的测试仍然能成功运行。但是，我们又获得了新的功能，如果你想使用TestNG运行单元测试，那么感谢Surefire插件的维护者，你已经可以使用TestNG了。你也能运行支持注解的JUnit4单元测试。不用升级Maven安装或者新装任何软件，你就能获得这些功能。更重要的是，除了POM中一个插件的版本号，你不需要更改你项目的任何东西。这种机制不仅仅适用于Surefire插件，项目使用Compiler插件进行编译，通过Jar插件变成JAR文件，还有一些插件生成报告，运行JRuby和Groovy的代码，以及一些用来向远程服务器发布站点的插件。Maven将一般的构建任务抽象成插件，同时这些插件得到了很好的维护以及全局的共享，你不需要从头开始自定义你项目的构建系统然后提供支持。你完全可以从Maven插件获益，这些插件有人维护，可以从远程仓库下载到。这就是基于Maven插件的全局性重用。1.5.一个“项目”的概念模型Maven维护了一个项目的模型，你不仅仅需要把源码编译成字节码，你还需要开发软件项目的描述信息，为项目指定一组唯一的坐标。你要描述项目的的属性。项目的许可证是什么？谁开发这个项目，为这个项目做贡献？这个项目依赖于其它什么项目没有？Maven不仅仅是一个“构建工具”，它不仅仅是在类似于make和Ant的工具的基础上的改进，它是包含了一组关于软件项目和软件开发的语义规则的平台。这个基于每一个项目定义的模型实现了如下特征：依赖管理由于项目是根据一个包含组标识符，构件标识符和版本的唯一的坐标定义的。项目间可以使用这些坐标来声明依赖。远程仓库和项目依赖相关的，我们可以使用定义在项目对象模型（POM）中的坐标来创建Maven构件的仓库。全局性构建逻辑重用插件被编写成和项目模型对象（POM）一起工作，它们没有被设计成操作某一个已知位置的特定文件。一切都被抽象到模型中，插件配置和自定义行为都在模型中进行。工具可移植性/集成像Eclipse，NetBeans，和InteliJ这样的工具现在有共同的地方来找到项目的信息。在Maven出现之前，每个IDE都有不同的方法来存储实际上是自定义项目对象模型（POM）的信息。Maven标准化了这种描述，而虽然每个IDE仍然继续维护它的自定义项目文件，但这些文件现在可以很容易的由模型生成。便于搜索和过滤构件像Nexus这样的工具允许你使用存储在POM中的信息对仓库中的内容进行索引和搜索。Maven为软件项目的语义一致性描述的开端提供了一个基础。1.6.Maven是Ant的另一种选择么？当然，Maven是Ant的另一种选择，但是ApacheAnt继续是一个伟大的，被广泛使用的工具。它已经是多年以来Java构建的统治者，而你很容易的在你项目的Maven构建中集成Ant构建脚本。这是Maven项目一种很常见的使用模式。而另一方面，随着越来越多的开源项目转移到Maven用它作为项目管理平台，开发人员开始意识到Maven不仅仅简化了构建管理任务，它也帮助鼓励开发人员的软件项目使用通用的接口。Maven不仅仅是一个工具，它更是一个平台，当你只是将Maven考虑成Ant的另一种选择的时候，你是在比较苹果和橘子。“Maven”包含了很多构建工具以外的东西。有一个核心观点使得所有的关于Maven和.Ant，Maven和Buildr，Maven和Grandle的争论变得无关紧要。Maven并不是完全根据你构建系统的机制来定义的，它不是为你构建的不同任务编写脚本，它提倡一组标注，一个一般的接口，一个生命周期，一个标准的仓库格式，一个标准的目录布局，等等。它当然也不太在意POM的格式正好是XML还是YAML还是Ruby。它比这些大得多，Maven涉及的比构建工具本身多得多。当本书讨