Open franck102 opened 1 year ago
Hi @franck102 -
Take a look at this issue https://github.com/square/square-java-sdk/issues/100
We are still assessing this internally, but your issue here seems similar. Let me know if you think something else is going on here!
Hi @zenmasterjobo , this is neither the same missing method nor the same library, so I doubt the issues are related.
As you can see the Square SDK depends on io.apimatic:okhttp-client-adapter:jar:0.1.6 which generates code trying to call okhttp's RequestBody.create method with arguments in the wrong order... something is wrong with the dependency tree below.
It is very possible that the problem comes from apimatic or okhttp3, but I don't have a workaround at this point...
[INFO] +- com.squareup:square:jar:29.0.0.20230517:compile
[INFO] | +- io.apimatic:core-interfaces:jar:0.1.7:compile (version selected from constraint [0.1,0.2))
[INFO] | | \- com.squareup.okhttp3:okhttp:jar:3.14.9:compile
[INFO] | +- io.apimatic:core:jar:0.4.5:compile (version selected from constraint [0.4,0.5))
[INFO] | \- io.apimatic:okhttp-client-adapter:jar:0.1.6:compile (version selected from constraint [0.1,0.2))
I had the same issue (before facing #100). You can have a look at my pom.xml file (relevant snippet is provided in #100 as well) for a workaround that works for me (just ignore the jakarta stuff).
Hi @zeppelinux ,
Could you post your dependency tree? I did try okhttp 4.11.0 and that didn't help... not surprisingly since the create method expects the media type as the first argument.
The problem seems to come from io.apimatic.okhttpclient.adapter.OkClient.convertRequest calling create with an old signature, but I can't find a more recent version of io.apimatic:okhttp-client-adapter.
Hey @franck102 there is some weirdness going on in the square pom. I spent some time trying to get to the bottom of it, but didn't solve the root cause. Everything you need is in this comment, notice the usage of alpha version (nothing else works) https://github.com/square/square-java-sdk/issues/100#issuecomment-1534045771
Hey @franck102 there is some weirdness going on in the square pom. I spent some time trying to get to the bottom of it, but didn't solve the root cause. Everything you need is in this comment, notice the usage of alpha version (nothing else works) #100 (comment)
Thanks @zeppelinux , I finally managed to make this work thanks in part to your suggestions. Regarding Quarkus one critical change was to override the versions brought in by the quarkus BOM:
<dependencyManagement>
<dependencies>
<?SORTPOM IGNORE?>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>logging-interceptor</artifactId>
<version>5.0.0-alpha.11</version>
</dependency>
<dependency>
<groupId>com.squareup.okhttp3</groupId>
<artifactId>okhttp</artifactId>
<version>5.0.0-alpha.11</version>
</dependency>
<dependency>
<groupId>io.quarkus.platform</groupId>
<artifactId>quarkus-bom</artifactId>
<version>${quarkus.platform.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<?SORTPOM RESUME?>
@franck102 I'm glad to hear my suggestion helped! I don't see any exclusions in your snippet though... Are you sure you are not getting two okhttp jars in the classpath?
š @zeppelinux Thank you very much for contributing your thoughts and guidance on this!!
No worries @zenmasterjobo, it's all what Open Source is about, right? š»
@franck102 I'm glad to hear my suggestion helped! I don't see any exclusions in your snippet though... Are you sure you are not getting two okhttp jars in the classpath?
I do have the exclusions you suggested, but in <dependencies> - they won't be taken into account in the dependencyManagement section (see the maven docs).
Quarkus anyway never included two jars for a given maven coordinate; but what I can recommend if you use Quarkus is to go check the target/quarkus-app/lib/main directory for the jars actually included in the Quarkus runtime, as opposed to trusting the output of mvn dependency:tree/list
: Quarkus seems to have its own logic to resolve the dependencies.
I am not out of the woods yet since there seems to be some kind of interaction between the okhttp and okhttp3 libraries (or more likely their transitive dependencies), my Square API calls only work if I break the SendinBlue APIs by adding those exclusions:
<dependency>
<groupId>com.sendinblue</groupId>
<artifactId>sib-api-v3-sdk</artifactId>
<exclusions>
<exclusion>
<groupId>com.squareup.okhttp</groupId>
<artifactId>okhttp</artifactId>
</exclusion>
<exclusion>
<groupId>com.squareup.okhttp</groupId>
<artifactId>logging-interceptor</artifactId>
</exclusion>
<exclusion>
<groupId>com.squareup.okio</groupId>
<artifactId>okio</artifactId>
</exclusion>
</exclusions>
</dependency>
It may be that a comon okio version solves the issue, but I haven't had time to test that yet.
Hi @franck102, the dependencyManagement exclusions work as expected as long as they applied not to
Describe the bug A basic java SDK project trying to create a location generates an okhttp NoSuchMethodError with the first payment API request.
Expected behavior The
_client.getLocationsApi().createLocation(request)
call should succeed.To Reproduce Steps to reproduce the bug:
Square SDK version
What I tried
I tried downgrading to 28.0.0.20230419 (as shown in the dependency tree below), same exception.
By default there is a dependency convergence issue with io.apimatic:io.apimatic; adding this entry in dependencyManagement solves the convergence issue, but the exception still occurs:
What I tried: without dependency convergence
Exception raised:
Maven dependency tree: