frodo
frodo copied to clipboard
android10
Hardcoded bintray fetching of runtime
We're doing debug build where frodo is enabled on our Jenkins, which resides in a rather restricted environment, meaning that no outgoing HTTP traffic is allowed and dependencies are fetched through an internal Nexus instance.
When I build with frodo enabled on that machine, I get
> Could not resolve com.fernandocejas.frodo:frodo-runtime:0.8.1.
> Could not get resource 'http://dl.bintray.com/android10/maven/com/fernandocejas/frodo/frodo-runtime/0.8.1/frodo-runtime-0.8.1.pom'.
> Could not GET 'http://dl.bintray.com/android10/maven/com/fernandocejas/frodo/frodo-runtime/0.8.1/frodo-runtime-0.8.1.pom'.
Is there any way to make this configurable?
Also, may I request that you set up bintray's easy sync to Maven central? That would be super-cool :) Thank you!
@tommyd3mdi can you try if the problem is fixed? It seems that frodo-runtime was not included in jcenter().
Problem is that we cannot access jcenter() on our Jenkins and that we have our own separate Nexus set up that only proxies to Maven Central. The issue with jcenter() / bintray is really that it doesn't play completely nice with Nexus (see https://issues.sonatype.org/browse/NEXUS-9196) and that our admins will not include it therefor.
I'd just like to bump this and suggest that maybe it's not such a low priority!
This actually caused our dependency resolution to slow dramatically, as instead of hitting our internal repo (artifactory), it was hitting bintray first every time.
It should really just be part of adding the plugin that you need to also add the bintray dependency?
@athornz the reason why I put it low priority is because this does not affect the functionality of the library. And the process to add this to maven central is from the stone age and it takes forever.
The way we solved it at Soundcloud (for now), is that if you have a nexus server, just download the jars and add them manually to your internal repo.
Is it not a simple fix to remove the adding of the bintray repository from the plugin, and adding it as a step in the readme though?
@athornz the idea was to avoid as much configuration as possible. We have not suffered from that slowness you are mentioning dough. It is weird, could you give more context please?
It's due to Gradle trying to resolve dependencies against the repositories in the correct order.
The plugin adds the bintray repository at a very early stage, before any repositories declared in my build script are added. Gradle will check the bintray repo first for every dependency it tries to resolve.
I think it even checks bintray for the android support dependencies. Because it's a network call that slows down the dependency resolution.
@athornz good point. Maybe you can send a PR if you know how to solve it.