Question

Maven 一定可以为你节省不少时间。我敢肯定，一定是这样的。如果把 Maven 用得恰到好处，你将不必再为维护一套本来已经足够聪明的程序式构建系统而花费精力（参阅：过度工程（over-engineered））。但是，和其他任何技术一样，Maven 自身也存在一些问题：它的开发文档仍然有些粗糙，甚至有些插件（例如 Hibernate3 插件）还没有完整的文档。

注意：如果 Mojo 提供的 Hibernate3 插件文档不能让你感到满意，应该批评 Tim 了。他现在正和 Mojo 的维护人员一起努力改进这个插件。希望当你读到这本书时，Hibernate3 插件已经具备完整的文档了。如果还没有，那就随便给他发个邮件催一下吧。

向开发团队中引入某种技术非常不容易，尤其是那些对构建结构或数据库设计之类的东西有特殊要求的技术。我曾经见到过有些团队拒绝 Hibernate，是因为 Hibernate 的合集映射不符合数据库管理员的标准。也见到过某些组织拒绝 Hibernate，是因为它创建的 SQL 达不到开发团队认可的标准。对 Hibernate 的批评还有些是非常抽象的，听起来好像是什么时髦的艺术评论家的言论（“关系数据库是一种过时的结构”）。对于类似的这些不理性的批评，Maven 也不是它们的陌生人。无论如何，我们当中肯定就有这样的人，因为可能必须接受某种标准，所以就不愿意使用可以节省时间的技术。如果你决定采用 Maven 这种构建工具，那么在开始使用它之前，务必要保证团队中的每个人都要接受这种声明式（declarative）构建的思想。

在下一章中，我打算介绍另一种通过提供标准和约定来节省更多时间的技术。你刚看到 Maven 是如何负责项目的构建，才让你有时间坐下来放松一会儿。第 13 章将向你演示如何用 Spring Framework 来完成 Hibernate 的大部分编码工作。就像 Maven 让项目构建变得不费力气一样，Spring 让使用 Hibernate 变得更加容易。使用这种节省时间的技术也会有一定的风险：只需要花费片刻的延迟就完成了很多繁杂的任务，你的老板可能因此发现原来你的工作这么简单，所以就开始给你分配一堆堆的任务。如果你担心像管理构建过程或编写模板代码这样繁杂的活都做完话，我建议你不必在意本章和下一章介绍的内容。另一方面，你可以接受 Maven 和 Spring，而用节省下来的时间多休息一会儿，早点回家，或者在 Safari 上阅读更多的在线电子图书也未尝不可。