6

我的客户需要一个更有条理的清单，其中包含在其项目生产中使用的所有 3rd 方库（例如 JAR 文件）。我参与了他们的许多基于 Java 的项目。他们的库存在过去并没有得到一致的维护，现在是时候考虑所有当前正在使用的库（有很多！）并强制执行将新库引入构建环境的结构化流程。

我尝试在构建过程中提出使用 Maven 和 Artifactory 的想法，以利用这些工具管理二进制库存储库和处理传递库依赖项的能力。客户拒绝接受这个建议，因为他们认为维护 Artifactory 服务器和学习 Maven 基础知识会给他们带来更多的工作量。

目前，他们的 Java 项目都是使用 Ant 脚本构建的。传递依赖在很大程度上是通过反复试验来管理的。当前使用的库清单由手工维护，二进制文件存储在 Subversion 存储库中。客户认识到这需要改进，但当前的改进建议涉及更多的临时“手动管理”方法。

我想说服客户 Maven 和 Artifactory 的组合是满足他们 Java 库管理需求的可行的现成解决方案。谁能指导我参考文献/材料，我可以使用这些文献/材料为我的客户创建关于 Maven 和 Artifactory 的功能和优势的演示文稿？

任何其他可以帮助我的论点/建议/等也将不胜感激。

4

1 回答 1

8

我想说服客户 Maven 和 Artifactory 的组合是满足他们 Java 库管理需求的可行的现成解决方案。

正如评论中指出的那样，您的客户不一定需要完全采用 Maven 才能从依赖管理中受益，您可以调整现有的 ant 脚本以使用Maven Ant 任务或 Ivy。这可能不那么可怕，并且已经消除了一些痛苦。

关于 Maven 管理依赖的方式，我简单解释一下：

  • 工件由坐标（groupId、artifactId、version）标识。
  • 这允许使用标准化的目录结构（存储库）来存储它们
  • 依赖项不仅仅是一个 JAR：它是一个带有 POM 的 JAR，它支持传递依赖项解析等事情。

这种依赖管理解决方案的好处是：

  • 没有任何依赖关系，它们是唯一标识的（不再是“那是什么版本？”综合症）
  • VCS 中没有更多的二进制数据（更快的结帐，更少的空间）
  • 更容易在项目之间重用工件（不再通过电子邮件发送 jar）
  • 通过传递依赖解析更容易管理

而且因为您不想依赖公共存储库，因为您需要存储自己的工件，所以您需要一个企业存储库。我个人的选择是 Nexus：

  • 因为它是基于文件的（与 Artifactory 不同，我不想将我的工件放在数据库中）
  • 因为它易于安装/使用
  • 因为它易于管理

以下是一些关于 Nexus 的资源（抱歉，我只是不使用 Artifactory）：

为了以防万一，这里有一些关于 Maven 的演示材料：

于 2010-10-07T21:54:59.413 回答