Maven权威指南中文版

Maven权威指南

来源: 241c40f5f705cc17552709d2/maven‐book/reference_zh/public‐book

Authors

Tim O'Brien (Sonatype, Inc.) , John Casey (Sonatype, Inc.) , Brian Fox (Sonatype, Inc.) , Bruce Snyder () , Jason Van Zyl (Sonatype, Inc.) , Juven Xu ()

Chapter 1. 介绍 Apache Maven

1.1. Maven... 它是什么?

1.2. 约定优于配置（Convention Over Configuration）

1.3. 一个一般的接口

1.4. 基于Maven插件的全局性重用

1.5. 一个“项目”的概念模型

1.6. Maven是Ant的另一种选择么？

1.7. 比较Maven和Ant

1.8. 总结

虽然网络上有许多Maven的参考文章，但是没有一篇单独的，编写规范的介绍Maven 的文字，它需要是一本细心编排的入门指南和参考手册。我们做的，正是试图提供这样的，包含许多使用参考的文字。

1.1. Maven... 它是什么?

如何回答这个问题要看你怎么看这个问题。绝大部分Maven用户都称Maven是一个"构建工具"：一个用来把源代码构建成可发布的构件的工具。构建工程师和项目经理会说Maven是一个更复杂的东西：一个项目管理工具。那么区别是什么？像Ant 这样的构建工具仅仅是关注预处理，编译，打包，测试和分发。像 Maven 这样的一个项目管理工具提供了构建工具所提供功能的超集。除了提供构建的功能，Maven还可以生成报告，生成Web站点，并且帮助推动工作团队成员间的交流。

一个更正式的Apache Maven的定义： Maven是一个项目管理工具，它包含了一个项目对象模型 (Project Object Model)，一组标准集合，一个项目生命周期(Project Lifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。当你使用Maven的时候，你用一个明确定义的项目对象模型来描述你的项目，然后 Maven 可以应用横切的逻辑，这些逻辑来自一组共享的（或者自定义的）插件。

别让Maven是一个"项目管理"工具的事实吓跑你。如果你只是在找一个构建工具，Maven能做这个工作。事实上，本书的一些章节将会涉及使用Maven来构建和分发你的项目。

1.2. 约定优于配置（Convention Over Configuration）

约定优于配置是一个简单的概念。系统，类库，框架应该假定合理的默认值，而非要求提供不必要的配置。流行的框架如Ruby on Rails和 EJB3 已经开始坚持这些原则，以对像原始的 EJB 2.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 签出一个项目如Apache ActiveMQ或Apache ServiceMix，然后从源码进行构建，你需要为每个项目留出一个小时来理解给它的构建系统。这个项目需要构建什么？需要现在什么类库？把类库放哪里？构建中我该运行什么目标？最好的情况下，理解一

个新项目的构建需要几分钟，最坏的情况下（例如 Jakarta 项目的旧的 Servlet API 实现），一个项目的构建特别的困难，以至于花了几个小时以后，新的贡献者也只能编辑源码和编译项目。现在，你只要签出源码，然后运行：mvn install。虽然 Maven 有很多优点，包括依赖管理和通过插件重用一般的构建逻辑，但它成功的最核心原因是它定义了构建软件的一般的接口。每当你看到一个使用 Maven 的项目如Apache Wicket，你就可以假设你能签出它的源码然后使用mvn install构建它，没什么好争论的。你知道点火开关在哪里，你知道油门在右边，刹车在左边。

1.4. 基于Maven插件的全局性重用

Maven 的核心其实不做什么实际的事情，除了解析一些 XML 文档，管理生命周期与插件之外，它什么也不懂。Maven 被设计成将主要的职责委派给一组 Maven 插件，这些插件可以影响 Maven 生命周期，提供对目标的访问。绝大多数 Maven 的动作发生于 Maven 插件的目标，如编译源码，打包二进制代码，发布站点和其它构建任务。你从 Apache 下载的 Maven 不知道如何打包 WAR 文件，也不知道如何运行单元测试，Maven 大部分的智能是由插件实现的，而插件从 Maven 仓库获得。事实上，第一次你用全新的 Maven 安装运行诸如mvn install命令的时候，它会从中央 Maven 仓库下载大部分核心 Maven 插件。这不仅仅是一个最小化 Maven 分发包大小的技巧，这种方式更能让你升级插件以给你项目的构建提高能力。Maven 从远程仓库获取依赖和插件的这一事实允许了构建逻辑的全局性重用。

Maven Surefire 插件是负责运行单元测试的插件。从版本 1.0 发展到目前广泛使 …… 此处隐藏：24709字，全部文档内容请下载后查看。喜欢就下载吧 ……