Android buildscript repositories: jcenter VS mavencentral

Question

The last time I used Android Studio, it generated .gradle files with mavencentral() buildscript repositories whereas now there's jcenter().

Could anyone explain the issues connected with this. Are there any other repos? When should we switch them? What impact do they have on projects, modules, libs? Any other essentials for Android developers?

Who's responsible for maintaining those repos?

Schacker

As @sgill mentioned, JFrog are the maintainers of Bintray and JCenter. If you have any specific questions, fire away :) – Across

Because.... Android. ;) – Ankeny

i.pinimg.com/originals/a2/cc/b2/… – Pensile

Answer 1

At Bintray I just rebloged a very detailed blog post describing the reasons why Google made this change. Here are the most important points:

• JCenter is a Java repository in Bintray, which is the largest repo in the world for Java and Android OSS libraries, packages and components.
• All the content in JCenter is served over a CDN, with a secure HTTPS connection. Back in the time of the migration (Android Studio 0.8) The central maven 2 repository was HTTP only and HTTPS wasn't supported. Reference: 51.6.2. Maven central repository.
• jcenter() is a superset of mavenCentral(), that encompasses many additional repositories and artifacts.
• In different scenarios and from different countries Bintray is faster than Maven Central (e.g. from Israel). In others it is very close. Since Maven Central and Bintray use different CDNs which adaptively favor regions, this might change to both ways.
• Bintray has a different approach to package identification than the legacy Maven Central. This is a big and serious security matter. It is important.
• If you really need to get your package to Maven Central (for supporting legacy tools) you can do it from Bintray as well, in a click of a button or even automatically.

Regarding performance improvements, couple of android developer advocates had faced/noticed the issue of huge indexing with maven central.

In the words of Tor Norbye:

I ran AndroidStudio with a brand new settings directory, so it went and connected maven central and downloaded an index of the available artifacts.

Then I happened to look at the size of my directory.

My ~/Library/Cache/AndroidStudioPreview is 1.5G, and 1.2G of those are taken by the “Maven” subdirectory.

That’s ridiculous. We barely use the index at all. The primary use for it is the Dependency editor in the Project Structure Dialog, but we really don’t need to have a precomputed index for it. MavenCentral has a fast online JSON search we can use on demand when somebody searches for artifacts. In https://android-review.googlesource.com/#/c/94843/ we added a lint check which checks whether the dependencies are up to date, and the search for a handful of artifacts is near instant.

In short, we really don’t need the cache; it may help with code completion in .gradle and maven .pom files, but that’s not a super important usecase, and certainly not something all users should have to sacrifice 1.5G of download speed and diskspace to have the possibility of one day doing. Read more on: The Maven index is huge!

Also, you might find this very short (1Q and 1A) discussion on Hacker News interesting.

---

^{I am with JFrog, the company behind bintray and artifactory, see my profile for details and links.}

Across

Answer 2

I was wondering the same, and I don't have a definitive answer but figured it might be worth sharing what (little) I'd learned. I found mention of the move from Maven Central to JCenter within one issue on Google Code, but didn't spot details about exactly when this happened - couldn't find mention in the recent changes list for Android Studio.

From reading up on JCenter, it is the repository behind Bintray, from the company JFrog (who I've come across before, and I guess that's where the 'J' comes from). According to the Bintray blog, Bintray is a superset of Maven Central, so if that's true there shouldn't be issues with missing dependencies, but I guess it's going to depend on exactly what you're using in your projects - you could always directly check the repos as both have nice easily-searchable websites. So for who maintains these repos, as best I know, it's up to the producers of the dependencies to add their dependencies to each repo, and up to the repo owner just to maintain the service.

In terms of when to switch it is difficult to work out. AOSP is still using Maven Central I think (from looking in Templates for New Android Application), but then that template is also still using a very old Gradle version (0.4) as well. There's a couple of issues about others having issues with dependencies from jcenter, but not really a lot reported, and it is possible that Google will switch again to some other repo before releasing AS final. If Maven Central is still working fine for you for now you could hold off switching until then especially if you're building large commercial solutions.

Filterable

You can also find the list of gradle-supported repositories here - including Maven Central, JCenter, and others: gradle.org/docs/current/userguide/… – Filterable

In the Gradle documentation about repositories it says that the Maven repo only supports the http transport protocol, while JCenter supports https. Google is a big fan of https, so perhaps that is their reason for switching? – Parkin

Just an update - as of RC2 of Android Studio, it's still JCenter, so I'd think that a good time to switch could be soon, when Android Studio goes final, after checking all your dependencies are available.... – Filterable

The Central Repository/Maven Central supports https just fine. – Braynard

Feb 2015 update: AS 1.1 RC 1, still jcenter() under buildscript/repositories – Brainless

Answer 3

No matter what the default is in the build.gradle file - in a team based development effort you should really use a repository manager like Sonatype Nexus or JFrog Artifactory and not reference those upstream repositories directly.

This will allow you to save a lot of bandwidth, combine both and many other repositories and manage it all in your own network.

In terms of Maven Central vs JCenter. JCenter is effort from JFrog to embrace, extend (and exterminate?) Maven Central. Maven Central is the default repository in Maven, SBT and others, while Gradle has switched to JCenter. This is not surprising considering that JFrog and Gradleware work together as companies. Since the Android SDK uses Gradle as build system now, the move to JCenter was a logic next step.

JCenter itself is a thin veneer on top of Maven Central. It proxies it (more or less successfully) and adds additional components. Both are hosted on CDN networks and highly performant. Maven Central itself is the target for all Eclipse, Apache and most other open source projects and without it JCenter would be mostly empty.

Using either of them will work fine, but I would suggest to go straight to the source where you can and on top of that take control of it by using a repository manager. Nexus Open Source for example is free and has support for Maven repositories as used by Maven, Gradle, SBT, Ivy and others as well as NuGet, NPM and RubyGems support.

Disclaimer: I am the author of Repository Management with Nexus and Nexus trainer for Sonatype, the sponsor of the free Central Repository, the project lead of the Android Maven Plugin and have pushed some Android libraries to Central by rebuilding from AOSP.

Braynard

According to the JFrog engineering team it does dynamically request artifacts from the Central repository. I would call that proxy .. if you want to call it something else thats up to you. – Braynard

E.g. my projects like the progressive organization pom or the android maven plugin and all others that are in Central all appear in jcenter. None of them are published anywhere else than Central so you have taken them from there. And thats fine. Jcenter is just another distribution platform. – Braynard

e.g. bintray.com/bintray/jcenter/… or bintray.com/bintray/jcenter/… – Braynard

Hahah .. JCenter only downloads from Central and then passes on to the users. – Braynard

Bintray never proxied Maven Central, at least not in this reality. You can call it whatever you want, but in the factual world Bintray never issued a single HTTP request to Maven Central ever. – Across

Baruch, Lets stick with the facts. E.g. the Android Maven Plugin is in jcenter even though it was ONLY deployed to the Central Repository. Try wget jcenter.bintray.com/com/simpligility/maven/plugins/… for yourself. I therefore conclude that jcenter somehow "proxied", "copied" or whatever it from Central. And thats totally fine by me. – Braynard

As your fellow answer-er @Across pointed out, you appear to be affiliated with Maven Central/Sonatype. If so, then I think that you have to disclose this affiliation in your answer as per stackoverflow.com/help/behavior – Hexagram

@Hexagram my profiles on stackoverflow/stackexchange, on linkedin, Google+ and other places all point out my affiliation with Sonatype. Your linked behaviour point explicitly states "Do not use signature, taglines, ..", however you are asking me to do just that. I answer a lot of questions and I am associated with many projects. It would be bad to litter all my answers with these disclaimers about who I am associated with. I also would not want Jbaruch to disclose his affiliation with jfrog/bintray or indirectly Gradle on each answer. Thats what a profile is for. – Braynard

And @Hexagram if you want to discuss this further I suggest we move this to meta. E.g. keep in mind that affiliations change over time (sometimes a LOT) and we would not want to have to update answers to reflect that all the time. – Braynard

A simple "I work for the company behind Maven Central" would be sufficient. That's not a signature of tagline. stackoverflow.com/help/behavior clearly states that "...you must disclose your affiliation in your answers." – Hexagram

I guess it's also not relevant that affiliations change over time. What matters is that at the time of writing this, you where employed by the company selling the product you mention in your answer and this question is about. – Hexagram

I disagree, but updated to make you happy ;-), Baruch should probably do that too since he is community advocate for Jcenter and JFrog, but I leave that up to his community sense. – Braynard

Manfred, at least I clearly state it in my profile. It took me a while to find your affiliation with Sonatype in writing. I won't claim that you deliberately hide it, but it's for sure not as obvious as mine. – Across

I just wear a lot of hats and do many things. Its in the list like all other activities. – Braynard

Answer 4

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

this article can answer you question .

At first, Android Studio chose Maven Central as a default repository. Once you create a new project from old version of Android Studio, mavenCentral() would be automatically defined in build.gradle.

But the big problem of Maven Central is it is not developer-friendly. It is surprisingly hard to upload the library to. To be able to do so, developer has to be at some level of geeky. And with some more reason for example a security concern and etc, Android Studio team decided to switch the default repository to jcenter instead as you can see that once you create a new project from latest version of Android Studio, jcenter() would be automatically defined instead of mavenCentral().

Dislimn