NoSuchMethodError when following FetchOnlineDataExample #600
Comments
benjaminaaron
changed the title
|
It seems the parameters to pass to
|
|
Could this be a conflict between WDTK's OkHTTP and your OkHTTP? Maybe two different versions of the library are in the classpath? You could perhaps find out with |
|
Good idea @wetneb, thanks. I am not sure if the correct OkHTTP version gets used in my case. When I run And the OkHTTP version Not sure how to interpret this 🤔 In the Lines 85 to 86 in 58d6de3 Should I be expecting OkHTTP version 5.0.0-alpha.2 to be used instead of 3.4.9?
|
|
When I remove the So no other dependency of mine is using them. I also removed the |
|
The pom.xml file in this repository is for the development version of WDTK, it is normal that versions of WDTK released in the past use other versions of this dependency. |
|
My solution for now is to have a |
|
I ran into the same exact problem just now. The only okhttp dependency in my tree comes from the wbtk-wikibaseapi: |
|
Ok, so in OpenRefine it works, and there we manually pin to okhttp 4.9.3. So let me just publish a new minor release with that dependency. We can then investigate why this is not even picked up at compilation time or in the tests. Very weird! |
|
Ok, we actually pull in two different versions of OkHTTP as dependencies of WDTK at the moment, hence the mess. Let me clean that up. |
|
What's the status of this bug? I guess it's related to reverting 536? |
|
I'm kind of confused what I would need to exclude. I'm only using the wdtk-wikibaseapi. Not sure where okhttp 5 would be coming from... |
|
Try this (untested): <dependency>
<groupId>org.wikidata.wdtk</groupId>
<artifactId>wdtk-wikibaseapi</artifactId>
<version>0.13.3</version>
<exclusions>
<exclusion>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>okhttp</artifactId>
</exclusion>
</exclusions>
</dependency>If you have other dependencies that pull in okhttp, you need to do the same for them. |
|
I tried this, but this just caused my project to miss okhttpClient. I think the quickest fix is to switch the RequestBody.create(.. arguments on line 447 of ApiConnection, though I do wonder why this does not cause a problem for everyone, as ApiConnection imports okhttp3.RequestBody |
|
Fine with me to try upgrading OkHTTP (but I am not sure why you think downgrading to stable would be more work - is there anything else to do beyond #694?) |
|
As you prefer! Let me merge #698 and make a patch release so that people can test it more easily. |
|
hey @Lhaaits, we just released a new version which could potentially solve this, can you check on your side if it works for you? |
|
0.13.4? |
|
Thanks! @robertvazan my offer to downgrade to stable okhttp still stands. I understand you do not like it because it downgrades Junit but it feels pretty important to me to solve this quickly. I will personally not have the time to embark on a big change of our testing architecture (by adding a dockerized Wikibase or by developing our own Wikibase-like server). |
|
@wetneb I cannot work on this immediately, because I have one other OSS project still in need of my attention. I might need a week or more to get this done. If the quick fix I offered before does not work and the issue is urgent, feel free to downgrade okhttp for now. If I find a way to do it better by replacing mockwebserver, I will begin my PR with reapplication of junit upgrade, so that the junit5 work is not lost. |
|
That sounds like a great plan! |
|
@Lhaaits how about 0.13.5? |
|
Still the same problem :/ |
|
|
3.14.9 is the only version of okhttp being imported. Still not sure why RequestBody.create in BasicApiConnection is expecting java.lang.String, okhttp3.MediaType |
|
Hmmm, I am not sure where "3.14.9" is coming from. This new version of WDTK depends on OkHTTP 4.2.2. Could you try adding an explicit dependency to |
|
|
|
Still uses okhttp:3.14.9, and still gives the error. I'll also try to get it to work locally and maybe make a pull request. |
|
@Lhaaits Did you remove the exclusion rule from your POM? |
|
I tried with and without exclusion rule for both okhttp-urlconnection and okhttp. In all cases it's still giving the same error. |
|
Okay so if I checkout commit 453eaf2 (the 0.13.5 commit) IntelliJ is saying that the 4.2.2 version of okhttp is conflicting with the 3.0.0-rc1 version, which comes from okhttp-signpost:1.1.0. Maybe when I'm using the 0.13.5 version in my application for some reason maven decides to use the 3.0.0-RC1 version, while wikibaseapi uses the 4.2.2 version? |
|
It's weird how the underlying dependencies my application seems to be importing are different from the ones wdtk-api is importing, for the same base version |
|
This is my application: |
|
This is the wikidata-toolkit fork: |
|
From your last screenshot, it looks like you are indeed using okhttp 4.2.2. Could it be that you have left the previous workaround in place (the |
|
I'm using BasicApiConnection to test the fixes. The top screenshot is my application, which for some reason won't use 4.2.2. Even after adding com.squareup.okhttp3:okhttp-urlconnection:4.2.2 to my pom: |
|
I would try adding an explicit dependency to |
|
Also adding com.squareup.okhttp3:okhttp:4.2.2 seems to work! I hadn't tried to add both okhttp-urlconnection and okhttp next to wdtk-wikibaseapi. Thanks! |
|
@wetneb Aren't we missing okhttp 4.x dependency in wikibaseapi module? It could spare downstream projects of the need to declare the dependency in their own POM. |
|
It sounds like a sensible move given @Lhaaits's experience indeed! |
I am using exactly the code from
FetchOnlineDataExample.java(from here) and nothing else:And get this error:
I have this in my
pom.xml:The text was updated successfully, but these errors were encountered: