Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardcoded bintray fetching of runtime #9

Open
realdadfish opened this issue Nov 12, 2015 · 11 comments
Open

Hardcoded bintray fetching of runtime #9

realdadfish opened this issue Nov 12, 2015 · 11 comments

Comments

@realdadfish
Copy link

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
Copy link
Author

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

@android10 android10 added the bug label Nov 12, 2015
@android10 android10 added this to the 1.0 milestone Nov 12, 2015
@android10
Copy link
Owner

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

@android10
Copy link
Owner

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

@realdadfish
Copy link
Author

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
Copy link
Owner

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

@josh-burton
Copy link

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
Copy link
Owner

@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
Copy link

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
Copy link
Owner

@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
Copy link

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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants