金字塔，古董，Maven中心和Sonatype Nexus…| JFrog

如何将一种技术或工具与其竞争对手进行比较?通常没有客观的比较。那么你怎么知道哪个更好呢?Eclipse还是IntelliJ IDEA?Java EE还是Spring?c#还是Java?你通常能在供应商网站上找到的是一场圣战和有偏见的比较。

但幸运的是，有时候，你可以找到一个公平的比较。这是怎么发生的?由利益相关者共同撰写。的二进制存储库比较矩阵是稀有资源之一。2022世界杯阿根廷预选赛赛程由JFrog，Sonatype而且Archiva提交者为您提供一个客观的画面;每个供应商都添加新功能，并观察其他供应商，以确保每个人都公平竞争。

标题指的是Maven，事实上，这三个都是很棒的Maven存储库。但这就是道路开始分离的地方。两个存储库管理器仍然只为Maven提供“一流的支持”。一个是超越。现在，专注于Maven并没有什么错(我们也非常关注Maven)，但是当涉及到技术时，落后是必然会失败的。

哪个存储库管理器提供给您完整的支持。net, npm, Python, Ruby, Yum, Debian和Docker(是的，包括浏览，搜索和元数据)?

哪个存储库管理器拥有一种基于此元数据搜索工件的完整查询语言，因为这就是您考虑工件的方式(例如，您想要在目标平台上工作并通过所有质量门槛的最新文件)?

哪个存储库管理器支持你的DevOps文化?开发人员和运维人员都信任并共同使用。它既支持与开发相关的工件，如jar和gems，也支持与操作相关的工件，如deb、rpm和码头工人图像。

无论是你的VCS、CI服务器还是存储库管理器，当你的交付管道中的一个工具出现故障时，整个组织都无法构建。哪个存储库管理器提供真正的主动/主动高可用性架构?

远程团队可以使用相同的存储库，但是，哦，延迟。哪个存储库管理器支持任何网络和防火墙拓扑结构，具有完全的推、拉和事件驱动复制．

那些产品创造者无法想象的场景呢?您需要一个支持组织CI/CD流的存储库管理器，而不是一个“我行我道”的方法。哪个存储库管理器是否可以很容易地使用易于编写和部署的用户插件进行扩展．

有一天，我遇到了这样的说法:“迁移到‘我们的东西’的一个很好的理由是，它是使用最广泛的。”即使假设“最广泛使用”的说法是正确的(我们不能这样假设)，从什么时候开始，最受欢迎==更好?我清楚地记得EJB 2比Spring框架流行得多的日子。即使在今天，COBOL也比Groovy更受欢迎，更不用说Scala或其他很酷的语言了(说的是古董!)有趣的是基于这一点，Sonatype正在敦促组织从Artifactory转换到Nexus!

回一个锁定到Maven2的哑文件系统，没有CI服务器集成和对maven以外的任何东西的支持都非常有限(例如，在链接的博客文章中，对npm的支持甚至比。net还差)。回到不支持HA和有限复制的设置。听着，他们特别要求你排除元数据！“继续，删除这些重要的信息”他们说!那么，NO怎么样!

正如我们在JFrog中所说，一旦你向前跳，你就不会回头．甲骨文(Oracle)、瑞士信贷(Credit Suisse)、德意志银行(Deutsche Bank)、CA等数十家Nexus难民企业，以及超过1000家客户我们95%的用户留存率证明了这一点。

附注:想了解Nexus路线图吗?不需要特别的努力。看看Artifactory半年前发布的内容就知道了。令人惊讶的是，过去几年的预测是如此准确。

金字塔，古董，Maven中心和Sonatype Nexus…