logo标签列表

我们应该使用Nexus还是Artifactory作为Maven仓库？

maven-2nexusartifactory
119
我们正在使用 Maven 进行大型构建过程（>100个模块）。我们一直将外部依赖存储在源代码控制中，并使用它来更新本地仓库。
然而，我们准备升级到一个本地仓库，可以缓存中央仓库，这样我们就不必主动下载所有第三方插件了（但是我们仍然可以从本地仓库拉取）。此外，我们还想从每晚的构建中发布我们的内部构建产物，以便开发人员不必创建整个项目。
我们正在考虑 Nexus 和 Artifactory。有什么理由更喜欢其中一个？还有其他我们应该考虑的吗？
2
你的链接不太客观，这是另一方的回应：http://blogs.jfrog.org/2009/01/contrasting-artifactory-and-nexus.html - user58773
我认为你应该考虑使用像Apache或nginx这样的普通http服务器。它们是“无聊技术”（http://mcfunley.com/choose-boring-technology）。 - Johan Walles
5
在这种情境下更适合翻译为“不便利且降低生产力的技术”。 - Priidu Neemre
12个回答
119
我确定，如果你只是谈论从“mvn deploy”存储二进制文件，两者都可以很好地完成。
我们非常广泛地使用Artifactory，并进行了所有升级。有许多项目，大量快照被部署和外部存储库被代理。没有任何问题。我很难解释其他人如何遇到其数据库、索引或其他任何问题。我们从未遇到过这样的情况。此外，Artifactory允许将数据存储在磁盘上，仅使用DB来存储元数据，它非常灵活（在此处查看更多）。
使这些应用程序非常不同的是它们对与其他构建工具和技术的集成方法。Nexus和Sonatype几乎锁定在Maven和m2eclipse上。他们忽略其他任何东西，只是最近开始致力于他们自己的专有Hudson集成（请参见他们的Maven 3网络研讨会）。 编辑：截至2017年，这种说法已经不再正确，Nexus为其他构建工具提供了更大的支持。编辑结束 Artifactory提供了惊人的Hudson、TeamCity和Bamboo集成，以及Gradle / Ivy支持。因此，当您走出Sonatype“舒适区”（Maven、m2eclipse）时，Nexus将无法为您提供任何帮助，而Artifactory则与所有主要构建工具合作。
事实上，能够在Hudson完成作业后部署构建工件，而不是通过“mvn deploy”，这是一个巨大的区别：Artifactory Hudson插件会一次性地部署所有工件，仅在构建作业成功完成时。如果构建作业在中途失败，则“mvn deploy”会在每个模块之后运行，并且可能只部署部分工件集。从Maven在模块完成时进行部署，而不是从构建服务器在作业完成时进行部署，真的是一件糟糕的事情。
正如您所看到的，Artifactory在思考时“超越框架”，而Nexus则只关注Maven和Maven工件。
使Artifactory更易于访问的另一个因素是他们的基于云的Artifactory Online解决方案。每月约80美元，您就拥有自己的Artifactory实例，无需为其专门分配任何服务器。

Artifactory拥有一个简单易懂的REST API，不确定Nexus的API如何工作。 编辑Nexus 也具有REST API，同样也很容易使用。

总之，对于Maven构件的基本存储，我认为两者都可以。 但是，虽然Nexus只是严格的“Maven仓库管理器”，Artifactory则继续发展，成为任何构建工具和CI服务器的通用“二进制存储”。

9
抱歉，但我在这里闻到了恐惧、不确定和怀疑（FUD）的味道。 Nexus肯定不是“只与Maven和m2eclipse一起使用”，它可以很好地与Jenkins、TeamCity和Bamboo集成。它有一个简单明了的REST API;每个Nexus功能都作为REST端点公开。不能说Nexus“只关心Maven和Maven构件”;它还支持.Net（NuGet）、Gradle/Ivy、OSGI，并可托管Yum RPM存储库。在构件存储方面，tar、zip、rar、par包含在标准java存档类型之外。 - RCross
25
兄弟，那个回复是4年前发布的 :) 那现在已经不是关于Maven了吗？那太好了！ - Evgeny Goldin
4
@EvgenyGoldin的评论仍然很相关（除了FUD部分^^）。 - OddDev
4
既然这篇文章已经七年了，而REST API如今在工具中几乎成为必备品，但Nexus在这方面仍然表现不佳。使用Nexus3时，REST API基本上就是远程过程调用（RPC）；您需要上传一个小脚本来执行想要做的事情。另一方面，Artifactory似乎提供了一个深思熟虑且文档完备的API。 - thecoshman
76

我不知道Artifactory，但以下是我使用Nexus的原因：

  • 安装非常简单（自1.2版本以来，升级也变得非常简单）
  • 非常好的Web用户界面
  • 易于维护，几乎没有管理开销
  • 提供最近安装、损坏的构件和错误的RSS订阅源
  • 它可以组合多个仓库，所以您可以镜像多个源，但在settings.xml中只需要一个或两个条目
  • 从Maven部署开箱即用（无需使用WebDAV等技巧）。
  • 它是免费的
  • 您可以重定向访问路径（即某些损坏的pom.xml需要从“xxx”获取“a.b.c”）。而不是修补POM，您可以在Nexus中修复错误，并将请求重定向到构件实际位于的位置。
3
Nexus拥有出色的Web用户界面，可用于创建定期计划任务以清除快照。Artifactory目前还没有这个功能。 - Dave
27

Artifactory支持文件系统和数据库存储后端，存储是基于校验和的，相同的二进制文件只会存储一次，无论它们在存储库中出现多少次，这使得Artifactory在存储方面更加高效。由于这种架构，移动和复制也非常便宜（在Nexus中，没有用于移动/复制的REST API - 您必须在文件系统上移动内容，然后对存储库运行纠正操作以让其知道内容已更改）。

另一个重要的区别是Artifactory与Hudson和TeamCity具有独特的集成功能，可以捕获与构建运行相关的部署工件、解决的依赖项和环境数据的信息，从而提供完整的构建可追溯性。

1
Artifactory也支持S3持久化。 - Tim Ferrell
@TimFerrell，这话并不是错的，但对于我通常工作的大多数商铺来说，这个价格太贵了，无法承受。 - Sander Verhagen
22

Artifactory将构件存储在数据库中，这意味着如果出现问题，所有的构件都会丢失。Nexus使用平面文件来存储您珍贵的构件，因此您不必担心它们全部丢失。

3
这也是让我们与众不同的原因。我想这主要只是一种偏执症，但知道随时可以检查系统让人感到安慰。 - Jeremy Huiskamp
5
因为这个原因，我们计划从Artifactory转换到Nexus。 - Kariem
2
又有一个腐败的受害者点赞了；从那时起，我一直在使用Archiva和Nexus，两者都非常可靠。 - SimonJ
73
此回答已过时。Artifactory现在可以配置为将对象存储在文件系统上。 - sourcenouveau
38
自从我开始使用Artifactory，它就对实际构件有文件系统支持。但由于我们的主要数据库服务器已经复制并备份，所以我还是使用数据库。我不明白为什么文件系统存储本质上比数据库更安全。这并不是针对Nexus，只是想澄清一下。 - Joshua Davis
显示剩余3条评论
9
如果您需要任一产品的“Pro”功能（例如暂存库、工件推广、NuGet），那么您需要考虑不同的定价模型，这些模型在它们的网站上显示。

总结：

  • Artifactory Pro
    • 你需要按服务器付费
    • 你可以为增加的服务时间付更多的费用
  • Nexus Pro
    • 你需要按座位付费，即下载工件的开发人员人数
    • 支持服务仅在周一至周五0800-2000 ET提供，无论你支付多少钱

无论你有多少用户，Nexus Pro都提供了与Artifactory的每年7450美元的“Silver Value Pack”基本相当的支持服务。

每年7450美元大约可以购买67个Nexus Pro座位（1-50个座位108美元，其余座位120美元）。

仅从价格和支持方面而言，直到达到67个用户，Nexus Pro才是更合理的选择。此时Artifactory成为更便宜的选项。

然而，如果你所有的支持工作都在内部进行，那么这个魔法点大约是23个用户（Artifactory的最基本的支持方案是每年2750美元）。

8

我最近做了一些关于Artifactory 2和Nexus 1.3的研究。下面是我发现的主要区别：

  • Artifactory将元数据和可选文件存储在数据库中，Nexus直接写入文件系统。每种方法都有优缺点。数据库支持事务，而存储在文件系统中的文件可以直接访问。
  • Artifactory需要更高的系统要求，尤其是对于磁盘空间的需求。

最完整的比较：http://binary-repositories-comparison.github.io/

实际上，Artifactory现在是GPL。 - Brian Fox
5
Nexus OSS现在已经支持LDAP多个版本。 - Brian Fox
1
Artifactory对LDAP 群组的支持仍然是专业版功能：http://www.jfrog.com/confluence/display/RTF/LDAP+Groups - Steven Magana-Zook
1
更新于2015年7月：Codehaus现已关闭，因此矩阵迁移到http://binary-repositories-comparison.github.io/。 - JBaruch
7

你应该使用Artifactory 它的最新版本是一个真正的飞跃 你可以增量备份你的仓库，这意味着你可以保存所有的构件并保持更新 它有一个易于使用的web界面 而且非常容易设置 我非常喜欢它 看看它的新版本2.0

5
从学习者的角度来看，我注意到两者之间有一些特定的区别。
  1. 目前Sonatype不支持在Jboss应用服务器上进行.war部署，但可以在Tomcat下运行。
  2. 目前Sonatype没有为我提供Amazon Machine Image（AMI），以便我快速测试和使用。
  3. Bitnami提供了一个Artifactory AMI，只需要几分钟就可以启动并配置好，取决于您想要实现什么。
  4. Artifactory在云中提供SaaS版本，因此您可以专注于完成任务，而不是基础设施问题。
  5. 我没有使用过Nexus，但我发现Artifactory非常直观和易于配置，至少在最初阶段如此。
  6. 补充说明-我注意到Artifactory用户指南可能对经验丰富的专业人士来说可以，但对于某些深入解释方面略显不足。例如，刚开始时，我们需要解压缩并添加一个仓库，例如RedHat的JBoss EAP Enterprise Repo。一切都很顺利，但当我尝试查看导入的工件时，Artifactory报告零个工件？没有错误或警告，所以现在我正在寻找一个解释。这是正常现象还是异常情况？文档中简单的解释可以迅速指引一个人朝着正确的方向前进。作为一个好的贡献者，我将这些评论添加到项目中，以使其他入门者受益。
3

不考虑政治/宗教因素，对于某些组织来说，许可证确实有所区别。

Nexus现在使用的是Eclipse Public License (EPL)许可证，不再是GPL和AGPLv3许可证了，详情请见发行说明。

Artifactory产品在2.1版本之后改用LGPLv3许可证，不再是Apache许可证，详情请见该产品页面。

出于比较的目的，您也可以考虑使用Archiva，其采用的是Apache 2.0许可证。

5
好的，我会尽力进行翻译。以下是需要翻译的内容：为什么，这是一个巨魔。Linux 是 GPL 协议，这是否会让组织不想使用它？把一个工具整合到程序中和使用它是有区别的。 - Tim O'Brien
4
对于一些组织（包括我的组织），在使用 GPL 许可的软件时非常谨慎，担心会有法律风险。我不想讨论这种策略的明智程度 - 我猜我们完全同意。只是指出对于一些人来说，这很重要。 - Zac Thompson
1
从2.1版本开始，Artifactory已经是LGPL了。 - Brian Fox
1
@Zac @user145026 你们是否将代码链接到Nexus库？如果没有，我不明白为什么GPL许可证会成为问题。 - Pascal Thivent
1
我认为每个人都应该阅读并理解这个帖子的第一条评论。使用GPL软件（如Linux、Git等）和将其纳入您的产品之间存在差异。您是否计划重新分发Artifactory？ - Nicolas C
显示剩余3条评论
2
3
  1. 这张图片不准确，因为它只依赖于 Maven Central 的调用。还有其他的下载来源。
  2. Codehaus已经关闭，矩阵已经迁移到http://binary-repositories-comparison.github.io/。
 - JBaruch
很好。你有更好的图片吗？ - rofrol
你可以在这里找到一些数字：http://www.jfrog.com/blog/2014-year-continuous-integration-revolution/。 - JBaruch
1
偏向Nexus，偏向jfrog - 我不会信任任何一组数字。 - Kyle Wiering
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接