search

android10 / frodo

Android Library for Logging RxJava Observables and Subscribers.
1.48k stars 101 forks source link

Hardcoded bintray fetching of runtime #9

Open realdadfish opened 8 years ago

realdadfish commented 8 years ago

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?

realdadfish commented 8 years ago

Also, may I request that you set up bintray's easy sync to Maven central? That would be super-cool :) Thank you!

android10 commented 8 years ago

I labeled this as a bug. Will work on this. Thanks for reporting.

android10 commented 8 years ago

@tommyd3mdi can you try if the problem is fixed? It seems that frodo-runtime was not included in jcenter().

realdadfish commented 8 years ago

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.

android10 commented 8 years ago

Ok! Now I get it @tommyd3mdi. Will look into the article you sent :)

josh-burton commented 8 years ago

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?

android10 commented 8 years ago

@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.

josh-burton commented 8 years ago

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?

android10 commented 8 years ago

@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?

josh-burton commented 8 years ago

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.

android10 commented 8 years ago

@athornz good point. Maybe you can send a PR if you know how to solve it.