Android buildscript 存储库：jcenter VS mavencentral

在 Bintray，我刚刚转发了 a very detailed blog post，描述了 Google 做出这一改变的原因。以下是最重要的几点：

JCenter 是 Bintray 中的一个 Java 存储库，它是世界上最大的 Java 和 Android OSS 库、包和组件的存储库。

JCenter 中的所有内容都通过 CDN 提供，具有安全的 HTTPS 连接。回到迁移时（Android Studio 0.8）中央 maven 2 存储库仅支持 HTTP，不支持 HTTPS。参考：51.6.2。 Maven 中央存储库。

jcenter() 是 mavenCentral() 的超集，它包含许多额外的存储库和工件。

在不同的场景和不同的国家，Bintray 比 Maven Central 更快（例如来自以色列）。在其他情况下，它非常接近。由于 Maven Central 和 Bintray 使用不同的 CDN，它们自适应地偏爱区域，这可能会改变为两种方式。

Bintray 的包识别方法与传统的 Maven Central 不同。这是一个重大而严重的安全问题。这很重要。

如果你真的需要将你的包放到 Maven Central（用于支持遗留工具），你也可以从 Bintray 中完成，只需单击一个按钮，甚至自动完成。

关于性能改进，一些 android 开发者倡导者已经面临/注意到使用 maven Central 进行巨大索引的问题。

用 Tor Norbye 的话来说：

我使用全新的设置目录运行 AndroidStudio，因此它连接了 maven Central 并下载了可用工件的索引。然后我碰巧查看了我的目录的大小。我的 ~/Library/Cache/AndroidStudioPreview 是 1.5G，其中 1.2G 由“Maven”子目录占用。这是荒谬的。我们几乎不使用索引。它的主要用途是项目结构对话框中的依赖关系编辑器，但我们真的不需要为它预先计算索引。 MavenCentral 有一个快速的在线 JSON 搜索，我们可以在有人搜索工件时按需使用。在 https://android-review.googlesource.com/#/c/94843/ 中，我们添加了一个 lint 检查，用于检查依赖项是否是最新的，并且对少数工件的搜索几乎是即时的。简而言之，我们真的不需要缓存；它可能有助于完成 .gradle 和 maven .pom 文件中的代码，但这不是一个非常重要的用例，当然也不是所有用户都应该牺牲 1.5G 的下载速度和磁盘空间才能有可能有一天这样做。阅读更多内容：Maven 索引非常庞大！

此外，您可能会发现这个 very short (1Q and 1A) discussion on Hacker News 很有趣。

^{我在 bintray 和 artifactory 背后的公司 JFrog 工作，有关详细信息和链接，请参阅 my profile。}

---

我也想知道，我没有明确的答案，但认为值得分享我所学到的（很少）。我发现提到了从 Maven Central 到 JCenter within one issue on Google Code 的迁移，但没有发现有关具体发生时间的详细信息 - 在 Android Studio 的最近更改列表中找不到提及。

通过阅读 JCenter，它是 Bintray 背后的存储库，来自 JFrog 公司（我以前遇到过，我猜这就是“J”的来源）。根据 Bintray 博客 Bintray is a superset of Maven Central，如果这是真的，那么缺少依赖项应该不会有问题，但我想这将取决于您在项目中使用的确切内容 - 您可以随时直接检查 repos两者都有很好的易于搜索的网站。因此，据我所知，对于谁维护这些存储库，依赖项的生产者将其依赖项添加到每个存储库中，而由存储库所有者负责维护服务。

就何时切换而言，很难解决。我认为 AOSP 仍在使用 Maven Central（通过查看 Templates for New Android Application），但该模板也仍在使用非常旧的 Gradle 版本（0.4）。有一些关于其他人与 jcenter 的依赖关系存在问题的问题，但报告的并不多，而且 Google 可能会在发布 AS final 之前再次切换到其他一些 repo。如果 Maven Central 现在仍然可以正常工作，那么您可以推迟切换，特别是如果您正在构建大型商业解决方案。

---

无论 build.gradle 文件中的默认值是什么 - 在基于团队的开发工作中，您应该真正使用像 Sonatype Nexus 或 JFrog Artifactory 这样的存储库管理器，而不是直接引用那些上游存储库。

这将允许您节省大量带宽，将两者和许多其他存储库结合起来，并在您自己的网络中进行管理。

就 Maven Central 与 JCenter 而言。 JCenter 是 JFrog 为拥抱、扩展（和消灭？）Maven Central 所做的努力。 Maven Central 是 Maven、SBT 等的默认存储库，而 Gradle 已切换到 JCenter。考虑到 JFrog 和 Gradleware 作为公司一起工作，这并不奇怪。由于现在 Android SDK 使用 Gradle 作为构建系统，因此转移到 JCenter 是合乎逻辑的下一步。

JCenter 本身是 Maven Central 之上的薄薄的一层。它代理它（或多或少成功）并添加其他组件。两者都托管在 CDN 网络上并且具有高性能。 Maven Central 本身是所有 Eclipse、Apache 和大多数其他开源项目的目标，如果没有它，JCenter 将大部分是空的。

使用它们中的任何一个都可以正常工作，但我建议您直接访问源代码，并在此基础上通过使用存储库管理器来控制它。例如，Nexus Open Source 是免费的，并且支持 Maven、Gradle、SBT、Ivy 等使用的 Maven 存储库以及 NuGet、NPM 和 RubyGems 支持。

免责声明：我是 Sonatype 的 Repository Management with Nexus 和 Nexus 培训师的作者，免费 Central Repository 的赞助商，Android Maven 插件的项目负责人，并通过从 AOSP 重建将一些 Android 库推送到 Central。

---

http://inthecheesefactory.com/blog/how-to-upload-library-to-jcenter-maven-central-as-dependency/en

这篇文章可以回答你的问题。

起初，Android Studio 选择 Maven Central 作为默认存储库。从旧版本的 Android Studio 创建新项目后，mavenCentral() 将在 build.gradle 中自动定义。但 Maven Central 的最大问题是它对开发人员不友好。将库上传到其中非常困难。为了能够做到这一点，开发人员必须具有某种程度的极客。出于安全考虑等原因，Android Studio 团队决定将默认存储库切换到 jcenter，因为您可以看到，一旦您从最新版本的 Android Studio 创建新项目，jcenter() 将被自动定义而不是 mavenCentral()。

---