我不会参加整个Maven辩论，但可以说我是所有最佳实践的坚定支持者，对我而言，Maven是最佳实践的体现。 我的意思是说，Maven是围绕特定的最佳实践构建方法构建的。 注意，我说了一种特定的最佳实践构建方法。 在现实世界中，有不止几种构建方法可以胜任最佳实践，但是Maven假设其中只有一个。 这并不意味着其他人都不好，而只是意味着如果您使用Maven，则需要接受其假定的约定 。 。 。 或受苦。 对于任何“约定优于配置（CoC）”工具都是如此，并且Maven真是太糟糕了。

像所有设计模式一样，Maven是构建软件过程的可重用解决方案。

我认为偶尔讨论的Maven作为构建设计模式的概念是一个强有力的隐喻。 它很有用，因为它强调Maven与所有设计模式一样，是构建软件过程的可重用解决方案。 这是一个最佳实践解决方案，经过多年的大量使用，这些社区已经由聪明人改进。 利用设计模式构建软件的最明显好处与编写软件的好处相同。 即：

• 您无需手动编写即可获得大量功能
• 了解适用于一个项目的模式的工程师可以立即了解适用于另一项目的模式。

名义上，第一个是生产力，第二个是简单。 显然，每个人都希望提高生产力，即用更少的代码行完成更多工作。 但是，我实际上认为第二点-简单-更为重要。 我认为，整个工程领域可以归纳为“管理复杂性”的概念。 就复杂性而言，我直接指的是当您被成堆的意大利面条代码轰炸时感到的头痛。 设计模式通过以较高级别的注释密封大量的复杂性来帮助消除这种智力上的不和谐。 万一您忘记了，这就是我们腾出更多精力处理不可避免地驻留在下一个级别上的更大更酷的任务的原因。

正是这种观点使我将学习新项目的临时构建列为职业最烦人的方面之一。 即使非常干净地实施了ant或make生成，遵循了本地化的最佳实践并实现了软件生命周期的广泛自动化，它仍会用大量原始数据（即脚本行）来惩罚新开发人员。 请注意，这只是临时性 。 当然，这并不是敲响这些工具。 ant尤其擅长自动化任务并提供可重用的构建小部件集。 但是，它无助于为构建软件的整个过程提供可重用的解决方案，因此，它也无助于简化新开发人员理解构建的过程。

对于像Maven这样的CoC工具来说，最重要的约定是

因此，正如我所看到的，对于像Maven这样的CoC工具来说，最重要的是约定。 为了使Maven成功，您必须了解并遵循假定的约定。 不遵循约定的项目很快就会与Maven发生冲突。 首先，他们很难使用一种假定自己的构建过程的工具来实现自己的构建过程。 您很容易因无法轻松完成自己所做的事情而感到沮丧，但是前面的段落旨在表明实际上是您需要改变的人，至少在您打算继续使用Maven的情况下。 选择Maven时，您需要接受约定。 我不能，我建议您坚持使用Ant，它足够灵活，可以按您的条件满足您。 请记住，您正在失去利用Maven的设计模式方面来管理构建复杂性的能力。 如果您认为自己的构建没有复杂性问题，请向自己提出以下问题：

• 我们团队中的每个工程师都可以轻松构建我们软件系统的所有组件吗？
• 我们的工程师有信心修改构建脚本而不会感到焦虑吗？
• 当需要有人解决构建问题时，我们的工程师会逃离房间吗？

因此，如果您到目前为止与我在一起，您可能会同意遵循Maven假定的惯例是进入Maven必杀技的关键先决条件。 这就是导致我得出Maven文档糟糕的结论的原因。 它们不仅不足，而且可能有害。 他们主要记录配置，而完全没有遵循关键的主题。 我认为对配置的强调在很大程度上是偶然的，这使新手认为配置Maven是可以的，甚至是正常的。

Maven文档不仅不足，而且可能有害。 它主要记录了配置，而完全未能遵循约定的关键主题。

通过文档，我主要是指访问Maven或Codehaus插件页面时发现的所有内容。 例如，考虑极其核心的maven-assembly-plugin。 浏览Maven网站上的文档 ，您会发现它几乎完全与配置有关。 正如我已经陈述和重申的那样，问题在于您真的不想配置Maven。 您想遵循约定。 配置应仅是最后的选择。

插件放东西，然后下一个插件找不到那个东西。 使用配置文件告诉Maven在哪里可以找到东西，然后没有该配置文件，其他任何人都找不到该东西。 配置Maven使您陷入配置反馈循环中，并且配置的几何增长不会使其具有pom可读性。 即使可以通过配置Maven使Maven满足您的需要，您也会很快得到一个难以理解的构建。

使用配置更改一个插件放置东西的位置，然后下一个插件找不到该东西。

因此，请避免配置！ 而是坚持走常规路线。 您的工程师将知道并喜欢他们的构建，并且您将轻松利用Maven生态系统提供的许多好处-从丰富的插件库到存储库服务器和构建服务器。

但是如何学习Maven约定呢？ 这都是关于社区的。 幸运的是，这是一个非常友好的社区。 这是我在尝试确定应如何在Maven中完成工作时使用的一些最重要的资源。

• Sonatype博客
• 堆栈溢出
• Maven用户列表

另外，为了成为一个友好的社区成员，我正在使用此博客条目作为一系列Maven条目的介绍。 这些条目中的每一个都会概述重要的Maven约定。 我将详细介绍约定并提供示例poms。 因此，如果您想了解Maven约定，请保持联系。

参考： Maven不吸。 。 。 但是我们的W4G合作伙伴 Chad Davis 的Maven Docs Do来自zeroInsertionForce博客。