对比Artifactory和Nexus
通过
5分钟阅读
我不太关心来自产品供应商的产品比较，因为他们通常是有偏见的，写的是一种“我如何让我的产品看起来更好”的心态。从一开始就被贴上“我不客观”的标签，我倾向于对他们缺乏信任。
我最近遇到了一个博客来自Sonatype的布莱恩·福克斯(Brian Fox)试图将这两款产品进行对比。Sonatype为Artifactory提供竞争产品Nexus Pro。hth华体会最新官方网站在JFrog，我们真的很喜欢这场比赛，并从中受益，因为它给了我们很多动力和方向，告诉我们如何变得更好。然而，这种比较完成在这个博客里其实不是很有用的一个。它不仅是写的首要目标是寻找缺点在Artifactory中，但不幸的是(或者实际上，对Artifactory来说是幸运的)，几乎所有提出的观点都是从完全错误到纯粹的FUD。
让我们依次看一下每个点:
1.网络:WebDAV vs. REST
作者建议Artifactory使用WebDAV和Maven。这是完全错误的!我不知道这个“事实”是从哪里来的，但这不是真的——Artifactory公开了一个纯HTTP/REST接口(GET/PUT)， Maven的HTTP马车使用了这个接口。
也许这种糟糕的评估来自Artifactory也提供WebDAV客户端支持的事实，但这是一个额外的功能，在HTTP / REST支持．
因此，假设Artifactory会更慢，就像作者所做的那样(因为他们过去尝试过WebDAV，发现它很慢)是完全无关紧要的。
顺便说一句，我们发现Maven WebDAV马车在处理大文件部署时表现得更好，而且在客户端消耗的内存也少得多。
2.存储:关系数据库与文件系统
出于某种原因，作者抛弃了其他更广泛使用的存储库所使用的健壮架构，例如:SVN、YUM、APT-GET等等。
当元数据不存在时，关于“重新修复”丢失的元数据的神奇故事就不起作用了可以从纯文件数据(如文件名和路径)。元数据必须作为一个整体与数据一起传输。如果我想知道最初是谁部署了工件，我就无法从文件名中恢复这段信息。
它还有更多的功能，比如当您删除和生成工件时，Artifactory确保您的删除、maven元数据和索引都作为一个事务进行更新—无需调度作业或手动修复将在以后破坏构建的恼人的不一致。
Artifactory 2存储现在非常可靠，而且我们还完全支持增量备份(包括增量元数据)。磁盘错误可能会使您的整个存储变得不可读(至少在没有复杂的恢复工作的情况下，LVM有人吗?)，我希望亲自遇到不进行备份的配置经理。抱歉，但是说您的数据处于危险之中，因为您正在使用数据库存储，这只不过是FUD。
3.存储大小
这可能是对的，可能有几个原因，比如保持更丰富的指数。不管怎样，除非你用的是3年旧机器，那么坦白说，谁在乎呢?真的，您选择一种产品的标准是否会因为一种产品使用的存储空间少了几gb ?如果是，建议检查硬盘可用现在在服务器和消费者机器上。对于消耗>64MB内存的情况也是如此(尽管我们使用默认VM堆运行Artifactory)。来吧……
4.Nexus不会干扰
默认情况下，Artifactory对存储库污染采取保守的方法，并试图保护您免受Maven中央存储库周围的一些混乱，主要是旧的遗留工件。大多数错误的POM规范都可以在repo1上的正确坐标下找到，因此Artifactory会产生一个有意义的错误，敦促您更正POM规范。
无论如何，这种保护可以很容易地关闭，通过进入artifactory.system.properties文件并注释掉下面这行:artifactory．maven．suppressPomConsistencyChecks = true。再说一次，这是不相关的。
当然，Sonatype博客所做的比较是不客观的。对于竞争对手来说，这是很自然的，当然，我不希望它提到Artifactory的优点，比如简单性和出色的用户体验，集成的UI驱动的LDAP集成，您不必支付3,000美元，支持在settings.xml中加密用户密码，查找和删除跨目录的遗留部署模块，一组工件的单一部署，本地存储库导入等。但是，这种比较也是不相关的，因为它依赖于错误或缺失的信息，有时是纯粹的FUD。
我们非常感谢Sonatype的各位贡献围绕Maven生态系统。你想推销你的商业产品也是很自然的，但是当你决定通过试图让其他产品看起来很糟糕来推销你的产品时，这是非常不幸的。hth华体会最新官方网站同样令人遗憾的是，我没有把宝贵的时间花在开发Artifactory的新功能上，而是用这些时间来清理这些错误的信息。整个社区都在享受我们的努力，所以让我们为他们提供好的开源产品，并在生产方向上投入时间。hth华体会最新官方网站
