需要演示材料来说服客户使用Maven

Jim*_*ugh 6 maven-2 repository ivy dependency-management artifactory

我的客户需要一个更有条理的所有第三方库(例如JAR文件)的库存,这些库用于他们项目的生产.我参与了许多基于Java的项目.他们的库存在过去并没有得到一贯的维护,现在是时候考虑到当前正在使用的所有库(有很多!),并强制实施一个结构化的流程,以便将新库引入构建环境.

我尝试过在构建过程中使用Maven和Artifactory的想法,以利用这些工具管理二进制库存储库和处理传递库依赖关系的能力.客户拒绝接受该建议,因为他们认为这将为他们创建更多工作来维护Artifactory服务器并学习Maven的基础知识.

目前,他们的Java项目都是使用Ant脚本构建的.传递依赖主要通过反复试验来管理.目前正在使用的库的库存是手工维护的,二进制文件存储在Subversion存储库中.客户认识到这需要改进,但目前的改进建议涉及更多的临时"手工管理"方法.

我想说服客户,Maven和Artifactory的组合是他们的Java库管理需求的可行的现成解决方案.任何人都可以指导我使用文学/材料来为我的客户创建关于Maven和Artifactory的特性和优势的演示文稿吗?

任何其他论据/建议/等将有助于我这一点也将不胜感激.

Pas*_*ent 8

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

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

关于Maven管理依赖关系的方式,我只想解释一下:

  • 通过坐标(groupId,artifactId,version)标识工件.
  • 这允许使用标准化的目录结构(存储库)存储它们
  • 依赖性更像是JAR:它是一个带有POM的JAR,可以实现传递依赖性解析等功能.

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

  • 没有依赖的混乱,它们是唯一标识的(不再是"那是什么版本?"syndrom)
  • VCS中没有更多的二进制数据(更快的结账,更少的空间)
  • 更容易在项目之间重复使用工件(不再通过电子邮件发送罐子)
  • 使用传递依赖性解析更容易管理

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

  • 因为它是基于文件的(与Artifactory不同,我不想将我的工件放在数据库中)
  • 因为它安装/使用简单
  • 因为它很容易管理

以下是有关Nexus的一些资源(对不起,我只是不使用Artifactory):

以防万一,这里有一些关于Maven的演示材料: