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

Support okhttp3 in the public interface of grpc-okhttp #8732

Open
beatrausch opened this issue Dec 1, 2021 · 5 comments
Open

Support okhttp3 in the public interface of grpc-okhttp #8732

beatrausch opened this issue Dec 1, 2021 · 5 comments
Milestone

Comments

@beatrausch
Copy link
Contributor

Is your feature request related to a problem?

grpc-okhttp does not support okhttp3 compatible versions in its public interface e.g. OkHttpChannelBuilder.

Describe the solution you'd like

Add support for okhttp3 to the public api e.g. OkHttpChannelBuilder to make it easier to use with okhttp3 compatible versions

Describe alternatives you've considered

Stick to the old version of okhttp 2

Additional context

Support both okhttp and okhttp3 in the public interface.

@beatrausch
Copy link
Contributor Author

Hi,

after adding the current version of okhttp3, I get the following error during the upper bound check

Execution failed for task ':grpc-okhttp:checkUpperBoundDeps'.
> Could not resolve all dependencies for configuration ':grpc-okhttp:runtimeClasspath'.
   > Could not resolve com.squareup.okhttp3:okhttp:4.9.3.
     Required by:
         project :grpc-okhttp
      > No matching variant of com.squareup.okhttp3:okhttp:4.9.3 was found. The consumer was configured to find a runtime of a library compatible with Java 7, packaged as a jar, and its dependencies declared externally but:
          - Variant 'apiElements' capability com.squareup.okhttp3:okhttp:4.9.3 declares a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares an API of a component compatible with Java 8 and the consumer needed a runtime of a component compatible with Java 7
          - Variant 'javadocElements' capability com.squareup.okhttp3:okhttp:4.9.3 declares a runtime of a component, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 7)
                  - Doesn't say anything about its elements (required them packaged as a jar)
          - Variant 'runtimeElements' capability com.squareup.okhttp3:okhttp:4.9.3 declares a runtime of a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component compatible with Java 8 and the consumer needed a component compatible with Java 7
          - Variant 'sourcesElements' capability com.squareup.okhttp3:okhttp:4.9.3 declares a runtime of a component, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 7)
                  - Doesn't say anything about its elements (required them packaged as a jar)

okhttp3 requires java 8. Any ideas on how to get it into the build?

@ejona86
Copy link
Member

ejona86 commented Dec 2, 2021

Note for others: this is related to #8610 and its fix #8650.

Hmm... that's troublesome. We can make it a compileOnly dependency, and maybe that will help, but I doubt it will. Since this is Gradle noticing, I suspect it may be difficult to workaround.

We can delay doing this a little bit, as Java 7 support should drop this quarter-ish (#4671). Really, I'd much rather figure out a way to tell Gradle "it's okay; ignore," but I have very little experience with Gradle Modules so I doubt I'll be too much help. I have seen this before, but in that case we stayed on the older version...

@beatrausch
Copy link
Contributor Author

Let's see, may be I could figure out way to work around that issue.

@beatrausch
Copy link
Contributor Author

Hi,

I was not able to work around that issue. Since the current version of grpc-java dropped Java 1.7, I would go for the solution which makes okhttp2 and okhttp3 compileOnly. To do that, I’d like to drop the okhttp2 dependency in the internal implementation e.g., in the OkHttpClientTransport (it is also related to #6119). According to #8004, the portion of okio used in grpc-java works with okio1 and okio2, thus I won’t expect an issue. What do you think?

@ejona86
Copy link
Member

ejona86 commented Feb 24, 2022

Removing the dependency on OkHttp from OkHttpClientTransport and then making okhttp2 a compileOnly dependency sounds great. I had intended to do that, but haven't had time. And adding okhttp3 API as compileOnly should be easier now without Java 7. I'll just recommend doing those things as two separate PRs.

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

2 participants