Maven 将作为一个普通的构建系统被人们重新认识并且它将超越 Java技术本文不打算成为一篇 Maven 教程而是将 Maven 与其他技术进行比较让您洞察 Maven 与 Eclipse 相适应的地方以及如何使这些工具相互协作
在过去几年中Maven 已经不仅仅是 Java 世界的一个时髦话题自 年起Maven 已经成为构建工具领域的先驱最近几年人们常拿它与 Ant 比较因为 Maven 与 Ant 有一些显而易见的相似之处所以拿它们俩作比较似乎是很自然的事
比如说在两种情况下XML 脚本都是可用的两种工具都可以生产工件它们还可以共享相同的分类法和概念比如 项目（project）目标（target）与 目标（goal）以及 依赖关系（depends） 和 先决条件（prereqs）但它们实质上有很大的差别
Ant 只是一个 XML 脚本工具而 Maven 是一个普通的构建工具它关注的重点是一个叫做项目对象模型（POM）的概念POM 暴露的是粗粒度的面向构建的任务这些任务被称为目标它们提供了一些准则帮助您开发构建方法和实现最佳实践
在某些方面Maven 属于软件工厂尽管目前它仍在外围更确切地说诸如 Maven 之类的构建工具是软件工厂领域中必不可少的
软件工厂
通过显着提高自动开发的级别软件工厂提供了一个花费更少更灵活的应用程序开发方法根据 Software Factories Web 站点的说法软件工厂是一个软件产品线它根据构建特殊种类的应用程序的方法配置一些可扩展的开发工具……提供打包的内容……以及指导
软件工厂涉及三个主要概念
模式提供了一些元数据描述组成应用程序的不同工件的结构以及它们是如何交互的 一个或多个模板提供了启动程序工具箱以及构建应用程序所需的其他任何东西 可扩展的开发环境用于配置定制和装配组件
如今这类工具已经逐渐引起了认识到它们的价值的那些工具制造人员工具开发人员和软件编辑的注意这些工具促进了软件开发过程的工业化降低了投入市场的成本和时间同时还提高了生产率加快了对进化需求的反应
仔细查看一下 Maven 的主要特性您就会认识到 Maven 与软件工厂之间的相似之处Maven 使用 POM 作为元数据来描述项目结构并通过通用应用程序插件来获得可扩展的项目模板
因为 Maven 非常灵活并且是开放源码的所以很容易推断和设想 Maven 是软件工厂平台中的一个核心组件但是还有另一种说法上述类比并不完全因为目前的 Maven 缺乏专用的开发环境而这类环境有助于创建特定于域或特定于企业的插件和模板并允许您轻松地配置项目或定制行为
不过Maven 的主要目标是标准化构建过程并保证代码构建测试部署（CBTD）循环中的质量和易再现性（easy reproducibility）它还可以制定度量标准帮助您了解开发状态
CBTD 本体论在软件工程领域已经不再新鲜但 Maven 可以使您标准化这种本体论并通过抽象这种理论将它想像成一个完整的实体考虑到不断增长的项目的复杂性标准化成为一种迫切需要
扩建的概念我们称之为元构建因为其无可估量的价值以及保证下一级质量的特性正逐渐被人们认识持续集成（continuous integration）就是建立在这个概念的基础之上但它也应用了在 IDE 上下文之外的地方进行构建的能力
模糊的界限
使用过 Java 技术的人应该都听说过 Eclipse 年年中的时候Eclipse 推出了它的第一个版本标志其成熟的是它为集成开发环境（IDE）提供了一个机会特别是为 Java 开发人员（不严谨地说）提供了一个机会
Eclipse 是一种开放的以语言为中心的平台也可以将它用作教育性项目和研究项目的基础平台其中一些平台捐赠给了 Eclipse 团体
就像 Microsoft已经采用软件工厂方法一样Eclipse 也开始转向模型驱动开发（MDD）方向并且最近已经公布了一个新的项目提议 —— 模型驱动的开发集成（MDDi）
根据该提议Eclipse MDDi 项目专用于平台的实现……其设计目标是支持各种建模语言（统一建模语言或特定于域的语言）和模型驱动的技术
渐渐地一些工具开始假定某些特性可以完全并且顺利地集成在一起Maven 和 Eclipse（即使作为一个简单的 IDE）也不例外因此从构建的角度来看二者似乎出现了重叠如图 所示
图 扩建的概念图描述的实际上是以前讨论的扩建概念正如以前定义的那样整个扩建过程包括几个任务同时还表示了一个元构建实例任务可以是以下两种类型之一原子任务是细粒度的并且是上下文不明确的这种任务的两个实例几乎是相同的宏观任务是复合任务它充当微观任务的容器
构建从扩展的意义上说只处理宏观任务原子任务的触发取决于配置这意味着用户对系统有着较高层次的看法这使得系统更易于维护和发展
此外Maven 和 Eclipse 都是开放的并且很容易通过插件扩展它们使其满足您的需要但是因为它们针对的受众不同所以它们之间的相似性也到此为止多数 Eclipse 最终用户是一些开发人员而 Maven 主要针对的是一些构建管理人员
尽管如此Maven 仍然是一个命令行工具虽然图形用户界面（GUI）是按照 Jason Van Zyl（Maven 的制造者和架构师）指示的方向开发的但 Maven 目前仍然没有帮助用户执行特殊任务的特定 GUI比如创建或更新配置或者只用一个鼠标单击发起构建
上面描述的典型构建顺序在 Eclipse 中不像在 Maven 中那么顺利Eclipse 的特性之一是开发 环境造成构建过程不连续这要归因于一些人为因素并不是每次成功编译之后都进行测试所有测试没必要一次运行可以跳过一些微观任务等等
各种因素都会导致产生差异这就是为什么开发人员每天至少必须运行一次完整的构建过程以确信他们没有破坏什么的原因
不过因为 Eclipse 是一个可扩展平台所以它受到许多用户社区的支持这使它成为驻留 Maven 驱动的开发允许开发人员和构建管理人员以某种简单的方式进行协作的理想之地
将 Maven 集成到 Eclipse 中 Mevenide 是 Codehaus 主办的一个项目旨在通过将 Maven 集成到 IDE 中简化 Maven 的使用
现在Borland Software 的 JBuilderNetBeans 和 Eclipse 都受到支持其他一些项目也部分地将 Maven 集成到 Eclipse 中这样就可以与 Mevenide（如 Maven Workshop）共享一些特性除了增加 Maven 的易用性之外为什么需要这种插件？
通过提供一些工具和视图让您了解 Maven 隐藏的复杂性并改进团队环境中的协作Mevenide for Eclipse 提高了生产率
从协作的角度来看假如构建已经被 Maven 化了那么最有用的特性就是 Eclipse 项目元数据与 Maven 元数据之间的双向同步如果开发人员忘记在向 Eclipse 中添加一个依赖关系之后更新 POM那么该怎么办？
如果重构无法传播到 Maven该怎么办？构建可能会中断或者一些单元测试可能被拒绝因此真的需要使 Eclipse 元数据和 Maven 元数据保持同步Mevenide 监听元数据的变化并使您能够很容易地确定元数据不匹配的地方这可以防止进行被严重破坏的构建
但 POM 并不只是关于依赖关系和项目布局的它还包含一些不用于结构上的项目管理信息比如版本号名称ID 和源储存库的位置Eclipse 元数据并不总是反映所有这些信息
因此需要另一个编辑这些信息的方法为此Mevenide 提供了一个图形编辑器该编辑器使 POM 的维护变得更容易并允许您避开一些烦琐的容易出错的原始 XML 手工编辑每个 POM 语义部分都被表示为一个编辑器页这增强了模型的整体可靠性
此外为了最大限度地减少创建 POM 的无聊过程Mevenide 提供了一个相当简单的可扩展的 POM 模板机制
阻止 Maven 在 Eclipse 之外的地方运行的能力是从类似 Mevenide 的插件中最容易获得的一项功能您可以选择某些执行任务（用 Maven 的术语来讲是 目标）这些任务可以是通过 Maven 插件全局定义的任务也可以是依赖于项目的任务或者您可以通过定义构建敏感的变量来定制构建
Eclipse 控制台上只显示了一些相关的选项（即在 IDE 的上下文中相关）对于其他任何插件控制台上只输出构建日志这一特性非常重要因为它避免了在控制台与 Eclipse 之间不停地来回奔波
Mevenide 还集成了其他许多帮助方法特性但它们不是很重要例如您可以定义给定目标与文件模式之间的关系这样就可以根据工作空间增加的增量来激活那些任务
您还可以浏览工件储存库或者根据名称搜索某个给定的工件（一个工件 就是一个构建结果它可以是 JAR 文件可执行文件或者是一个完整的 Web 站点）然后可以重定向到 Mevenide 站点获得完整的特性列表
不过仍然还有一个问题即使 Mevenide 增强了生产率和易用性但您仍然必须认识到哪些工具可以在特殊环境中满足您的需要通过 Maven Console 运行 Maven 会话可能非常耗时所以为了获得较高的生产率在对会话进行编码期间应该改为使用 JUnit 集成的 Eclipse 支持来运行测试并依赖于 Eclipse 的内部编译器来生成可执行的文件
