Maven不会吮吸。。。但是Maven文件会

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

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

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

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

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

正是这种观点使我将学习新项目的临时构建列为职业中最烦人的方面之一。即使非常干净地实施了ant或make build，遵循了本地化的最佳实践，并且自动化了软件生命周期的广泛范围，它仍然会用大量的原始数据（即脚本行）来惩罚新开发人员。请注意，这只是临时性 。当然，这并不是敲响这些工具。 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中完成工作时使用的一些最重要的资源。