maven的历史
Jason van Zyl 的 Maven 历史
Maven 的生命始于Jakarta Alexandria项目。Alexandria 项目现已不复存在，但它不仅是 Maven 的温床，也是Gump和Forrest项目的温床。原型源的第一次进口发生在 2001 年 8 月。截至本文档发布之日（2005 年 10 月），Maven 大约 3 年从亚历山大港被移除，7 个月前 Maven 大约 4 岁！Maven 在亚历山大港待了大约 5 个月，然后搬到了涡轮机项目的下一个家。
尽管 Maven 始于亚历山大，但其使用的测试平台是 Turbine 项目。Turbine 正在将其持久层、服务层和 Web 层解耦为单独的构建，我已经厌倦了不得不维护几个基本相同的不同构建。在那些日子里，没有办法简单地模板化 Ant 构建，每个 ant 构建似乎都不同，我发现这非常令人沮丧和徒劳。我想谁真正关心构建是如何工作的，只要它可以工作并且易于使用。项目的基础设施非常重要，但项目的价值在于正在开发的应用程序。因此，构建通常被忽略，并且在您最需要它工作时往往会分崩离析，就像您需要准备发布或当超过几个人在项目上工作时。四年前在雅加达的土地上，Ant 构建开箱即用的情况很少见。请注意，当我试图让 Maven 工作时，许多 Turbine 开发人员遭受了痛苦，这让我感到遗憾，但我想如果有人不遭受痛苦，新项目如何启动和生存。我认为这是为了他们自己的利益（众所周知，我有一两个意见），在咬牙切齿之后，我认为 Maven 终于成熟了。它让我想起了 Ralph Johnson 和 Don Roberts 在 Patterns for Evolving Frameworks 中我最喜欢的一句话：请注意，当我试图让 Maven 工作时，许多 Turbine 开发人员遭受了痛苦，这让我感到遗憾，但我想如果有人不遭受痛苦，新项目如何启动和生存。我认为这是为了他们自己的利益（众所周知，我有一两个意见），在咬牙切齿之后，我认为 Maven 终于成熟了。它让我想起了 Ralph Johnson 和 Don Roberts 在 Patterns for Evolving Frameworks 中我最喜欢的一句话：请注意，当我试图让 Maven 工作时，许多 Turbine 开发人员遭受了痛苦，这让我感到遗憾，但我想如果有人不遭受痛苦，新项目如何启动和生存。我认为这是为了他们自己的利益（众所周知，我有一两个意见），在咬牙切齿之后，我认为 Maven 终于成熟了。它让我想起了 Ralph Johnson 和 Don Roberts 在 Patterns for Evolving Frameworks 中我最喜欢的一句话：
人们通过从具体例子中进行概括来发展抽象。在没有实际开发运行系统的情况下，在纸上确定正确抽象的每一次尝试都注定要失败。没有人这么聪明。框架是可重用的设计，因此您可以通过查看它应该是设计的东西来开发它。你看的例子越多，你的框架就越通用。
我真的不知道最终结果会是什么样子，我只知道必须有更好的方法。但首先我知道我想要：
- 项目模型，以便您可以在一个地方查找与项目有关的所有内容
- 一个标准的目录结构，因此您不必四处寻找库、资源和文档
所以开始使用具有简单 XML 表示的模型，并选择了我认为是一些不错的目录结构标准，这就是它的开始方式。我仍然在幕后使用 Ant，但我有一些标准目标可以在每个 Turbine 构建中使用，这让我很高兴。
如上所述，当时亚历山大港的其中一个项目是 Gump。Sam Ruby 试图说服我使用 Gump 模型是一个好主意，所以我看了一下。在查看了描述符之后，我注意到 Gump 几乎允许任何项目在目录结构、在 CVS 中使用 JAR、每个项目有多个工件、文档随处可见以及其他一些没有意义的事情方面做任何事情对我来说，因为 Gump 当时并没有试图标准化任何东西，而是试图不断整合它可以得到的任何东西。我的目标不同，我想做一个 固执己见的人一个软件，我更喜欢约定的概念而不是配置。我希望一个项目的基础设施看起来和工作方式一样，所以我继续为一个项目追求我自己的模型，并决定不同意 Gump 在项目建模方面的特殊技巧，我认为它过于灵活。我想通过能够在同一个地方找到东西来节省人们的时间。同样，项目中的价值是最终结果：如何构建和构建可预测且容易的。我完全承认 Maven 1.x 中的一些缺陷有时会使事情变得更加困难，但这与第一代工具的课程相同。
接下来我注意到我们所依赖的所有 JAR 都存储在 CVS 中。我们有很多 Xerces 的副本，这很浪费空间，每次 Xerces 的版本发生变化时，我都必须在每个项目中更新 Xerces 的副本，但更重要的是，如果没有对您的依赖项进行一些声明性声明，就没有办法你可以进行任何分析。人们倾向于完全忽略关于声明性依赖使用的要点。人们说将他们的依赖项存储在 SCM 中非常容易，但是尝试将您的大型蹩脚构建分解为组件以鼓励重用和易于维护，或者尝试分析您在运行时可能需要的所有不同应用程序之间的公共依赖项图表，你真倒霉。声明式依赖的真正威力不在于您可以节省几个字节的磁盘空间，尽管如果您不小心，它确实可以加起来，而在于可以执行的分析。一旦你有一个像样的图表，所有的事情都是可能的。回到历史：既然存在声明性依赖关系，它需要变得更容易......
这时我决定在所使用的模型中采用标准的类似 Java 的继承，并找到一种方法来为需要构建的东西创建存储库。所以我破解了一些继承 goop，现在是存储库的时候了。我在 Apache 周围询问是否可以托管存储库，很快发现托管非 Apache 类工件是不可能的。所以 LGPL 和 GPL 工件都出来了，它们并没有真正成为一个有用的存储库。经过一番打猎后，我找到了Ibiblio这是一个包含大量免费软件在内的各种简洁内容的庞大档案。Ibiblio 的任务之一是帮助自由软件的传播。对我来说听起来很完美，所以我在 Ibiblio 与 John Reuning 取得了联系，剩下的就是历史了。与 Ibiblio 的人们一起工作很愉快，那里的管理员非常乐于助人和才华横溢。它们让我们存储我们想要的任何免费软件，提供出色的统计数据，并让我们托管我们想要的任何软件。Ibiblio 非常酷。
许多人在使用 Maven 1.x 时遇到了一些问题，但它通常可以工作，而且第一代中的所有工具都存在许多缺点，克服这些缺点的唯一方法是勇往直前并尝试在下一次创造更好的东西。鉴于 Maven 开发人员从 1.x 用户那里收到的所有反馈，并且在 2.0 的 beta 测试期间，我们认为我们终于有了可以构建的东西。Maven 的第一个版本是我自己在 Bob McWhirter 的帮助下编写的