Skip to content
This repository has been archived by the owner on May 1, 2023. It is now read-only.

Installing 'com.facebook.stetho:stetho-okhttp:1.0.0' breaks okhttp #59

Closed
bbade opened this issue Feb 20, 2015 · 10 comments
Closed

Installing 'com.facebook.stetho:stetho-okhttp:1.0.0' breaks okhttp #59

bbade opened this issue Feb 20, 2015 · 10 comments

Comments

@bbade
Copy link

bbade commented Feb 20, 2015

When I included this jar in my project, okhttp would crash when used with what looked like a proguard related issue.

I get the following error

Caused by: java.lang.NoSuchFieldError: No static field METHODS of type Ljava/util/Set; in class Lcom/squareup/okhttp/internal/http/HttpMethod; or its superclasses (declaration of 'com.squareup.okhttp.internal.http.HttpMethod' appears in /data/app/shiftgig.com.worknow-2/base.apk

i've tried whitelisting that file in proguard to no avail.

@jasta
Copy link
Contributor

jasta commented Feb 20, 2015

Were you previously using okhttp 2.2.0 without problems? This seems like just okhttp itself would fail, independent of stetho-okhttp.

@bbade
Copy link
Author

bbade commented Feb 20, 2015

Yeah, as soon as I comment out that lib in my gradle file, it works again.

@jasta
Copy link
Contributor

jasta commented Feb 21, 2015

Can you provide your proguard configuration? I'm trying to repro locally and am so far unable to. Not sure what's going on here or why adding Stetho would cause it.

@eleventigers
Copy link

I would suggest excluding okhttp from stetho-okhttp dependency, worked for me:

compile ('com.facebook.stetho:stetho-okhttp:1.0.0') {
        exclude group: 'com.squareup.okhttp'
}

@jasta
Copy link
Contributor

jasta commented Feb 21, 2015

Interesting. The weird thing with the way this works is that I'm really trying to declare that I can use okhttp 2.2.0+ in that module but that I don't really want to depend on it (I want the caller to make the dependency). Gradle doesn't seem to offer a way to do this that I can see. Perhaps this is why Square is still using Maven :)

@JakeWharton
Copy link
Contributor

You shouldn't use wildcard dependencies for anything. Just declare a dep on 2.2.0. If someone depends on 2.3.0 every dependency resolver (Gradle, Ivy, Aether) knows what to do.

@JakeWharton
Copy link
Contributor

Or, optionally, use a provided dep which is exactly what you described.

@jasta
Copy link
Contributor

jasta commented Feb 24, 2015

@JakeWharton awesome, thanks.

jasta pushed a commit to jasta/stetho that referenced this issue Feb 24, 2015
According to facebookarchive#59, it should be safe to just depend on 2.2.0 and ask the
dependency resolver to figure it out.
jasta pushed a commit to jasta/stetho that referenced this issue Feb 26, 2015
According to facebookarchive#59, it should be safe to just depend on 2.2.0 and ask the
dependency resolver to figure it out.
@longinoa
Copy link
Contributor

@bbade we just shipped 1.0.1 that has the fix for this can you retry now

@jasta
Copy link
Contributor

jasta commented Feb 27, 2015 via email

longinoa pushed a commit to longinoa/stetho that referenced this issue Mar 11, 2015
According to facebookarchive#59, it should be safe to just depend on 2.2.0 and ask the
dependency resolver to figure it out.
longinoa pushed a commit to longinoa/stetho that referenced this issue Apr 2, 2015
According to facebookarchive#59, it should be safe to just depend on 2.2.0 and ask the
dependency resolver to figure it out.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants