我们将所有源代码的依赖第三方 JAR 与我们的源代码一起检查到源代码控制中。需要时，我们会手动下载第三方 JAR 的更新，并将源代码控制中的那些 JAR 替换为较新的版本。我们还没有觉得有必要使用 Maven，因为这个过程对我们来说似乎很简单。但是我们是否因为不使用 Maven 而错过了一些有价值的东西？还是我们的场景不保证使用 Maven？
【问题讨论】：
“JARs 没有太大变化”，我一直听到这个......
在 SCM 中存储 jar 在项目开始时很简单。随着时间的推移，jar 的数量越来越大.... 等待 2 或 3 年，没有人记得 jar 来自哪里，它们的许可条款是什么，最常见的是正在使用什么版本（在分析安全漏洞时了解这一点很重要） .....
我最近读到的关于存储库管理器案例的最佳文章是：
有点不敬，但确实对人们一直遇到的那种技术惯性提出了一个有效的观点。
将项目团队从 ANT 切换到 Maven 可能会很可怕...... Maven 的工作方式完全不同，所以我发现最好与新开发或冒险的项目团队一起部署它。对于老派 ANT 用户，我建议使用 Apache ivy 插件。 Ivy 允许此类团队将其依赖项的管理外包，但保留他们熟悉的构建技术。
归根结底，使用 Maven 的最大好处不是依赖管理。这是标准化的构建过程。我已经看到几次创建“标准”ANT 构建过程的失败尝试。问题每个构建工程师对标准应该是什么都有自己的看法.... Maven 强制用户编写构建插件的方法一开始可能看起来有限制，但就像 iPhone 最终开发人员发现“有一个 Maven 插件”： -)
【讨论】：
当涉及到依赖管理时，Maven 确实非常有价值。正如 Mark O'Connor 所建议的，运行本地存储库管理器可能比将工件检查到源代码控制中更好。
有许多工具（如 eclipse 中的 m2e）可以帮助进行依赖管理，并就哪些模块或依赖项需要哪些其他依赖项提供有价值的反馈。即使不同的模块依赖于给定库的不同版本，Maven 也会确保获得适当版本的依赖项。这将有助于防止相同 jar 的重复版本出现在您部署的项目中，只要它们具有相同的组和工件 ID。
即使是一个非常简单的项目，我也不认为我会求助于将依赖项检查到源代码控制系统中。
【讨论】：
这不仅仅是关于第 3 方库。大多数情况下，如果您有多个存储库。在我们的例子中，我们有四个存储库，其中包含许多相互依赖和内部依赖。 实际上，我开始了这个答案，然后我不得不花 15 分钟与一些同事讨论在有人忘记更新另一个项目的 lib 目录中的一个项目的 .jar 后发生的问题。
而且看起来更专业:)
【讨论】：