Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
From pull request https://github.com/groovy/groovy-core/pull/261
Previously, the chain looked like this:
1. Grape's local cache
2. Maven local cache
3. Codehaus Maven repo
4. Maven Central
5. Java.net Maven repo
From what we saw, this chain has 2 problems:
1. Codehaus repo is relatively slow
2. Codehaus repo doesn't contain a lot of commonly used popular artifacts.
Those problems led to a slow resolution - all the requests suffered from Codehaus slowness and most of them then fell back to Maven Central anyhow.
We believe that adding Bintray's JCenter before Codehaus and Maven Central solves both those problems - it's much (much!) faster than Codehaus and it contains artifacts from both Codehaus, Maven Central, and much more (inc. Java.net repo and others).
In the rare case when the artifact is not present in JCenter yet, the resolution will continue to the rest of the default resolvers, and Bintray's smart self populating mechanism will fetch the missing artifacts asynchronously in the matter of minutes, which means that next user will be able to get the artifact from JCenter without falling back to additional repositories.
P.S. I had to exclude JCenter from the GrabResolverTests, since it's impossible to reproduce some of the failure conditions with Bintray, namely two:
1. It's impossible to resolve artifact without checksum from Bintray
2. I didn't manage to find an artifact that doesn't exist in Bintray but exists in some other popular repository (and even if I would, the test will pass just once, due to the self-populating nature of jcenter )