Android buildscript存储库：jcenter VS mavencentral
上次我使用Android Studio时，它使用mavencentral() buildscript存储库生成.gradle文件，而现在则有jcenter() 。
任何人都可以解释与此有关的问题。 还有其他的回购吗？ 我们什么时候该换？ 他们对项目，模块，库有什么影响？ Android开发者的任何其他必需品？
谁负责维护这些回购？
在Bintray，我刚刚重新发布了一篇非常详细的博客文章，描述了Google为什么做这个改变的原因。 以下是最重要的一点：
- JCenter是Bintray中的Java库 ，是Java和Android OSS库，包和组件中全球最大的回购站。
- JCenter中的所有内容都通过CDN提供，并具有安全的HTTPS连接。 在迁移的时候（Android Studio 0.8）中央Maven 2存储库只有HTTP，HTTPS不被支持。 参考： 51.6.2。 Maven中央存储库 。
-
jcenter()是jcenter()的一个超集，它包含许多额外的存储库和工件。 - 在不同的情况下，来自不同的国家，Bintray比Maven Central（例如以色列）要快。 在其他地方是非常接近的。 由于Maven Central和Bintray使用不同的适应性区域CDN，所以这可能会改变。
- Bintray与传统的Maven Central有不同的包装识别方法。 这是一个严重的安全问题。 这很重要。
- 如果你真的需要把你的软件包送到Maven Central（用于支持传统工具），你也可以通过Bintray来完成， 只需点击一下button，甚至自动完成 。
关于性能的提升，android开发人员的夫妇曾经遇到/注意到maven central的巨大索引问题。
用Tor Norbye的话来说：
我运行了一个全新的设置目录AndroidStudio，所以它去了，并连接maven中央，并下载了可用工件的索引。
然后，我碰巧看看我的目录的大小。
我的〜/库/caching/ AndroidStudioPreview是1.5G，这些1.2G的是由“Maven”子目录。
这是荒谬的。 我们几乎不使用索引。 主要用途是Project Structure Dialog中的Dependency编辑器，但是我们确实不需要为它预先计算索引。 MavenCentral有一个快速的在线JSONsearch，我们可以根据需要使用，当有人search工件。 在https://android-review.googlesource.com/#/c/94843/中，我们添加了一个lint检查，检查依赖关系是否是最新的，并且search几个工件几乎是即时的。;
总之，我们真的不需要caching; 它可能有助于在.gradle和maven .pom文件中的代码完成，但这不是一个超级重要的用例，当然不是所有的用户都必须牺牲1.5G的下载速度和磁盘空间才有可能在一天内完成。 阅读更多关于： Maven索引是巨大的 ！
另外，你可能会发现这个关于黑客新闻的非常短暂的（1Q和1A）讨论 。
我与JFrog ，背后bintray和artifactory的公司，看到我的个人资料的详细信息和链接。
我想知道的是，我也没有确定的答案，但认为可能值得分享我学到的东西（很less）。 我发现在Google Code的一个问题中提到了从Maven Central到JCenter的转移，但没有详细说明发生这种情况的细节 – 在Android Studio的最近更改列表中找不到提及。
从JCenter上的阅读来看，它是JFrog公司的Bintray背后的储存库（我曾经遇到过，我想这就是'J'的来源）。 根据Bintray的博客， Bintray是Maven Central的超集 ，所以如果这是真的，那么不应该有缺失依赖的问题，但是我想这将取决于你在项目中使用的是什么 – 你可以直接检查回购，因为两个都有很好的易于search的网站。 所以对于谁来维护这些回购，就我所知，依赖关系的生产者可以将它们的依赖关系添加到每个回购商，直到回购商维护服务。
在什么时候切换是很难解决的。 AOSP仍在使用Maven Central，我认为（从模板中查看新的Android应用程序），但是那个模板也在使用一个非常古老的Gradle版本（0.4）。 关于其他人有来自jcenter的依赖性问题，还有一些问题，但并不是很多，而且在发布AS final之前，Google可能会再次切换到其他一些回购。 如果Maven Central现在仍然在为您工作，那么您可以暂缓切换，特别是如果您正在构build大型商业解决scheme。
无论build.gradle文件中的默认值是什么 – 在基于团队的开发工作中，您应该真正使用像Sonatype Nexus或JFrog Artifactory这样的存储库pipe理器，而不是直接引用这些上游存储库。
这将允许您节省大量带宽，将两者和许多其他存储库结合起来，并在您自己的networking中进行pipe理。
就Maven Central和JCenter而言。 JCenter是JFrog努力接受，扩展（并且消灭？）Maven Central。 Maven Central是Maven，SBT和其他的默认存储库，而Gradle已经切换到了JCenter。 考虑到JFrog和Gradleware作为公司一起工作，这并不奇怪。 由于Android SDK现在使用Gradle作为构build系统，因此转向JCenter是下一步的逻辑。
JCenter本身就是Maven Central上面的薄木板。 它代理它（或多或less成功）并添加额外的组件。 两者都在CDNnetworking上托pipe，性能卓越。 Maven Central本身就是所有Eclipse，Apache和其他大多数开源项目的目标，没有它，JCenter将大部分是空的。
使用它们中的任何一个都可以正常工作，但是我build议直接find源代码，然后使用资源库pipe理器来控制它。 例如Nexus Open Source是免费的，并且支持Maven，Gradle，SBT，Ivy等人以及NuGet，NPM和RubyGems支持所使用的Maven仓库。
免责声明：我是Nexus和Nexus培训师的作者，Sonatype，免费的Central Repository的赞助商，Android Maven插件的项目负责人，并通过从AOSP重build了一些Android图书馆到Central。
http://inthecheesefactory.com/blog/how-to-upload-library-to-jcenter-maven-central-as-dependency/en
这篇文章可以回答你的问题。
起初，Android StudioselectMaven Central作为默认存储库。 从旧版Android Studio创build新项目后，mavenCentral（）将在build.gradle中自动定义。
但Maven Central的大问题是它不是开发人员友好的。 将图书馆上传至 为了能够这样做，开发人员必须在一定程度上令人讨厌。 另外还有一些原因，例如安全问题等，Android Studio团队决定将默认存储库切换到jcenter，因为您可以看到，一旦您从最新版本的Android Studio创build了新项目，jcenter（）将自动定义而不是mavenCentral（）。
