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