Maven 是一个基于模式的 Java 和 J2EE 项目构建框架,它不仅能对各类项目进行脚本化构建,而且支持 J2EE、Struts、Hibernate 等 框架技术,并且从项目的创建时刻贯穿到测试、打包到最后的部署,Maven 提供了一整套预设好的构造和组织项目的方法。Maven 的作者(在《Better Builds with Maven》一书中)是这样介绍 Maven 的:
Maven 包含了一系列构建标准、一个工件仓库模型(Artifact Repository Model),以及一个用来管理和描述项目的软件引擎。它为项目工件的构建、测试和部署定义了一个标准的生命周期,使得遵循其标准的项目可以轻松地重用常 用的构建逻辑。Maven 项目属于 Apache 软件基金会,它是一个开源社区,开发支持常用声明式项目对象模型(Project Object Model,POM)的软件工具。
Maven 和 ibilio 有一项合作协议,通过后者为项目编译所依赖的相关文件提供主机服务,这样使得基于 Maven 的默认安装时可以从已知的远程代码仓 库中取得所有所需的文件(这种机制很容易让人联想到 Gem,除了前者是以编译为核心方式)。拥有如此多的优点,基于 Maven 的项目貌似非常容易上手,其实不然,精简的外表下面涵盖的内容能写成一本 292 页的书。树大招风,由于它的宏伟目标,Maven 在过去曾经引发许多颇为强烈、而 Maven 的开发团队一直在致力于平息的反对声浪:
Maven 的最佳实践常常无法解决现实世界中企业存在的问题。即使我同意他们的看法,我也要反对那些存在于已有企业实践和 / 或当前工具集的问题。
就在本周,Matt Raible 报告了他将 AppFuse 从 Ant 迁移到 Maven 的经历:
迁移到 Maven 中最有趣的事情就是我们可以是 AppFuse 看起来更像一个框架,而不是一个项目启动工具包。我们认为这正是人们所需要的——特别是可以 为项目更新到 AppFuse 的最新版本。尽管有些人需要这个更新功能,但看起来更多人喜欢源码版本的 AppFuse——虽然这个版本很难以升级。我并不怪 他们。 当然,迁移到 Maven 的真正好处在其他地方也有,我们在最近这几个月已经看到邮件列表有明显得上升趋势,我也多次收到关于培训的咨询(是的,我确实提供 一个三天的关于 Spring、Hibernate、Ajax、Maven 以及 AppFuse 的培训)。对我来说,AppFuse 2.x 看起来要比 1.x 更为复杂,但是似乎社区并不是这样认为的。从不断增长的项目的活跃开发者来判断,开发人员似乎更喜欢基于 Maven 的项目。再重申 一遍,我们正在用 Maven!
自从 Maven 2 发布以后,各次升级(直到目前的 2.0.6 发布版)不间断地保持对核心引擎可用性的 Bug 修正和增量改进。代码仓库也不断地升级——包括对通用依赖包如 Spring 和 Tomcat,也包括对不那么通用的依赖包如 openid4java 和 mule 的最新支持。今年的早些时候,核心开发人员 Jason Van Zyl 和 John Casey 离开了 Maven 的主赞助商和商业支持提供商 Mergere 公司,但他们仍然继续积极参与 Maven 的开发活动。
评论