ApacheMaven：
[本系列博客是参照中文文档的总结，文档下载地址：(http://download.csdn.net/download/u012160163/9787289)
定义：
Maven是一个项目管理工具，它包含了一个项目对象模型 (Project Object Model)，一组标准集合，一个项目生命周期(ProjectLifecycle)，一个依赖管理系统(Dependency Management System)，和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。 当你使用Maven的时候，你用一个明确定义的项目对象模型来描述你的项目，然后 Maven 可以应用横切的逻辑，这些逻辑来自一组共享的（或者自定义的）插件。
设计原则：
（1）约定优于配置（Convention Over Configuration）：
Maven通过给项目提供明智的默认行为来融合这个概念.
默认目录：
在没有自定义的情况下，(basepath=/usr/local/hudson/hudson-home/jobs/maven-guide-zh-to-production/workspace/content-zh)
源代码假定是在: basepath/src/main/java ，
资源文件假定是在: basepath/src/main/resources。
测试代码假定是在: basepath/src/test 。
项目假定会产生一个 JAR 文件。
编译好的字节码假定放到: basepath/target/classes
并且在basepath/target 创建一个可分发的 JAR 文件。
一个定义好的生命周期和一组知道如何构建和装配软件的通用插件：
Maven 对约定优于配置的应用不仅仅是简单的目录位置，Maven 的核心插件使用了一组通用的约定，以用来编译源代码，打包可分发的构件，生成 web 站点，还有许多其他的过程。 Maven 的力量来自它的”武断”，它有一个定义好的生命周期和一组知道如何构建和装配软件的通用插件。如果遵循这些约定，Maven 只需要几乎为零的工作——仅仅是将你的源代码放到正确的目录，Maven 将会帮你处理剩下的事情。
注意：
使用“遵循约定优于配置”系统的一个副作用是用户可能会觉得他们被强迫使用一种特殊的方法。 当然 Maven 有一些核心观点不应该被怀疑，但是其实很多默认行为还是可配置的。 例如项目源码的资源文件的位置可以被自定义，JAR 文件的名字可以被自定义，在开发自定义插件的时候，几乎任何行为可以被裁剪以满足你特定的环境需求。如果你不想遵循约定，Maven 也会允许你自定义默认值来适应你的需求。
（2）定义一个够将软件一般的接口：
现在，大部分开源开发者已经或者正在使用 Maven 来管理他们新的软件项目。这种转变不仅仅是开发人员从一种构建工具转移到另外一种构建工具，更是开发人员开始为他们的项目采用一种一般的接口。随着软件系统变得越来越模块化，构建系统变得更复杂，而项目的数量更是如火箭般飞速上升。在 Maven 之前，当你想要从 Subversion签出一个项目如 Apache ActiveMQ 5 或 Apache ServiceMix 6 ，然后从源码进行构建，你需要为每个项目留出一个小时来理解给它的构建系统。这个项目需要构建什么？需要现在什么类库？把类库放哪里？构建中我该运行什么目标？最好的情况下，理解一个新项目的构建需要几分钟，最坏的情况下（例如 Jakarta 项目的旧的 Servlet API 实现），一个项目的构建特别的困难，以至于花了几个小时以后，新的贡献者也只能编辑源码和编译项目。现在，你只要签出源码，然后运行： mvn install 。虽然 Maven 有很多优点，包括依赖管理和通过插件重用一般的构建逻辑，但它成功的最核心原因是*它定义了构建软件的一般的接口。每当你看到一个使用 Maven 的项目，你就可以假设你能签出它的源码然后使用 mvn install 构建它，没什么好争论的。
（3）基于Maven插件的全局性重用:
Maven 的核心其实不做什么实际的事情，除了解析一些 XML 文档，管理生命周期与插件之外，它什么也不懂。Maven 被设计成将主要的职责委派给一组 Maven 插件，这些插件可以影响 Maven 生命周期，提供对目标的访问。
绝大多数 Maven 的动作发生于Maven 插件的目标，如编译源码，打包二进制代码，发布站点和其它构建任务。你从Apache 下载的 Maven 不知道如何打包 WAR 文件，也不知道如何运行单元测试，Maven大部分的智能是由插件实现的，而插件从 Maven 仓库获得。事实上，第一次你用全新的 Maven 安装运行诸如 mvn install 命令的时候，它会从中央 Maven 仓库下载大部分核心 Maven 插件。这不仅仅是一个最小化 Maven 分发包大小的技巧，这种方式更能让你升级插件以给你项目的构建提高能力。Maven 从远程仓库获取依赖和插件的这一事实允许了构建逻辑的全局性重用。
例如Maven Surefire 插件是负责运行单元测试的插件。从版本 1.0 发展到目前广泛使用的在 JUnit 基础上增加了 TestNG 测试框架支持的版本。这种发展并没有破坏向后兼容性，如果你使用之前 Surefire 插件编译运行你的 JUnit 3 单元测试，然后你升级到了最新版本的 Surefire 插件，你的测试仍然能成功运行。但是，我们又获得了新的功能，如果你想使用 TestNG 运行单元测试，那么感谢 Surefire 插件的维护者，你已经可以使用 TestNG 了。你也能运行支持注解的 JUnit 4 单元测试。不用升级 Maven 安装或者新装任何软件，你就能获得这些功能。更重要的是，除了 POM 中一个插件的版本号，你不需要更改你项目的任何东西。
(4)一个“项目”的概念模型:
Maven 维护了一个项目的模型，你不仅仅需要把源码编译成字节码，你还需要开发软件项目的描述信息，为项目指定一组唯一的座标。你要描述项目的的属性。项目的许可证是什么？谁开发这个项目，为这个项目做贡献？这个项目依赖于其它什么项目没有？Maven不仅仅是一个“构建工具”，它不仅仅是在类似于 make 和 Ant 的工具的基础上的改进，它是包含了一组关于软件项目和软件开发的语义规则的平台。这个基于每一个项目定义的模型实现了如下特征：
依赖管理：
由于项目是根据一个包含组标识符，构件标识符和版本的唯一的座标定义的。项目间可以使用这些座标来声明依赖。
远程仓库：
和项目依赖相关的，我们可以使用定义在项目对象模型（POM）中的座标来创建Maven 构件的仓库。
全局性构建逻辑重用：
插件被编写成和项目模型对象（POM）一起工作，它们没有被设计成操作某一个已知位置的特定文件。一切都被抽象到模型中，插件配置和自定义行为都在模型中进行。
工具可移植性/集成：
像 Eclipse，NetBeans，和 InteliJ 这样的工具现在有共同的地方来找到项目的信息。在 Maven 出现之前，每个 IDE 都有不同的方法来存储实际上是自定义项目对象模型（POM）的信息。Maven 标准化了这种描述，而虽然每个 IDE 仍然继续维护它的自定义项目文件，但这些文件现在可以很容易的由模型生成。
便于搜索和过滤构件：
像 Nexus 这样的工具允许你使用存储在 POM 中的信息对仓库中的内容进行索引和搜索。