将大型版本部署到 Maven Central

发布于 2024-10-14 07:16:54 字数 1012 浏览 3 评论 0原文

  1. Maven 中央存储库上的工件是否会过期?
  2. 每个工件的大小是否有大小限制?

我问这个问题是因为有些工件可能会变得非常大,我担心这可能会导致问题。

我给你举一个简单的例子。我的库依赖于 Boost C++ 库。 Boost 开始时有 241MB 的源文件(压缩后的 75MB)。编译时,每个编译器/平台组合(即 Visual Studio 2010、Windows、32 位)最终会生成 2.78GB 的​​二进制文件(压缩后的 200MB)。然后,您必须将该数字乘以您想要支持的平台数量。

一方面,我不希望用户自己构建 Boost,因为这是一个非常痛苦且漫长的过程。另一方面,我感觉每个版本上传 GB 的工件并不是正确的方法;)

我的库仅依赖于 Boost 的一个非常小的子集,所以从技术上讲我可以只上传该子集(以一定的成本)每个平台大约 10MB)。我担心长期会发生什么。如果更多的人开始使用 Boost 并且每个人都上传他们所依赖的子集,会发生什么......?

请参阅http://sourceforge.net/projects/boost/files/boost -binaries/1.44.0/ 有关如何拆分 Boost 模块的示例。正如您所看到的,各个模块都非常小。

之前也出现过类似的主题: http://maven.40175.n5.nabble.com/Best-practice-re-releasing-large-assemble-artifacts-td3250739.html但就我而言,我并没有尝试将程序集部署到中央。我正在尝试部署非常大的单个工件。

让我知道你的想法。

  1. Do artifacts ever expire on the Maven Central Repository?
  2. Is there a size limit to how big each artifact can be?

I ask because some artifacts can get very big and I am concerned that this may cause problems down the line.

I'll give you a simple example. My library depends on the Boost C++ library. Boost starts out with 241MB of sources (75MB compressed). When you compile it, you end up with 2.78GB of binaries (200MB compressed) per compiler/platform combination (i.e. Visual Studio 2010, Windows, 32-bit). You then have to multiply that number by the number of platforms you want to support.

On the one hand, I don't want users building Boost themselves because it is a very painful and lengthy process. On the other hand, I get the feeling that uploading GB of artifacts per release is not the right way to go ;)

My library only depends on a very small subset of of Boost so technically speaking I could upload just that subset (at a cost of approximately 10MB per platform). I am concerned about what will happen long-term. What happens if more people begin using Boost and each one uploads the subset that they depend on...?

See http://sourceforge.net/projects/boost/files/boost-binaries/1.44.0/ for an example of how Boost modules can be split up. As you can see, individual modules are quite small.

A similar topic has come up before: http://maven.40175.n5.nabble.com/Best-practice-re-releasing-large-assembly-artifacts-td3250739.html but in my case I am not trying to deploy assemblies into central. I am trying to deploy individual artifacts that happen to be very large.

Let me know what you think.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

生生漫 2024-10-21 07:16:54

我最终按原样发布了我的工件。尚未有人抱怨。

I ended up posting my artifact as-is. No one has complained yet.

來不及說愛妳 2024-10-21 07:16:54

注册本文档末尾链接的用户列表 然后我们来讨论一下。对于我们允许进入 Central 的内容没有硬性规定,但我想收集更多信息来帮助您以最有效和社区友好的方式构建内容。

中环的东西永远不会过期,并且没有具体的尺寸限制,尽管我们可能会仔细观察看起来尺寸过大的东西。

Sign up for the user list linked at the end of this document and then lets discuss it. There aren't hard and fast rules for what we allow into Central, but I'd like to gather more information to help you build things in the most efficient and community friendly way.

Things in Central never expire, and there isn't a specific size limit, although we may look closely at things that appear to be over sized.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文