我使用OkHttp3为纯Java应用程序构建了一个简单的连接API,并且遇到了一个构建问题,该问题似乎是由Square对多个依赖 Artifact 使用相同的包名称这一事实引起的。
我之前已经看过一些问答,讨论了Eclipse的Maven依赖关系和消息传递,但是所有这些都表明,即使Eclipse用模块错误对导入进行了注释,Maven或Gradle构建仍然有效。在这种情况下,只要我添加一个依赖项并且不进行其他任何更改,Gradle构建就会失败。
该应用程序是纯Java 11模块构建。我使用的是具有Gradle性质的最新Eclipse作为IDE,但是我认为这并不是严格意义上的。我正在使用OkHttp3将专用端点转换为API,并且这些端点之一需要CookieJar。希望仅使用默认实现,我将'com.squareup.okhttp3:okhttp-urlconnection:3.14.9'
作为依赖项添加到已经将'com.squareup.okhttp3:okhttp:3.14.9'
作为传递性依赖项的项目中。从技术上讲,这两个类都使用相同的包名称:“okhttp3”来提供类。
例如,我要做的就是取消注释此代码段中显示的依赖项行并保存build.gradle
:
dependencies {
implementation ('com.squareup.retrofit2:retrofit:2.9.0')
implementation ('com.squareup.retrofit2:converter-gson:2.9.0')
implementation ('com.squareup.okhttp3:logging-interceptor:3.14.9')
// implementation ('com.squareup.okhttp3:okhttp-urlconnection:3.14.9')
项目刷新后,我将在Eclipse中为的所有“okhttp3”导入获取批注:干净的生成导致:
$ ./gradlew clean build
[...]
> Task :compileJava FAILED
error: the unnamed module reads package okhttp3 from both okhttp3.urlconnection and okhttp3
error: module retrofit2.converter.gson reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
error: module retrofit2 reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
error: module org.apache.commons.io reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
error: module httpcore5 reads package okhttp3 from both okhttp3 and okhttp3.urlconnection
[...]
我认为这并不重要,但是我正在使用Gradle包装器5.6.4。据我所知,所有OkHttp3库都设置了足以满足Java 9+要求的模块信息。 Eclipse中的模块内容似乎对此感到满意。看起来Eclipse或Gradle都不像两个不同的依赖项将其Java包广告为“okhttp3”。在我看来,任何使用Java 9或更高版本的基于Gradle或Maven的项目都将因拆分包依赖性而失败。
根据我在其他地方阅读的一些建议,我尝试将
'com.squareup.okhttp3:okhttp'
从所有包含它的依赖项中移出,然后将其分别拉入,但这没有帮助(不是我以为会这样做,但是我正在尝试任何雹灾-玛丽)。解决方法包括简单地将我想要的两个Kotlin类直接拖放到项目中,然后以这种方式重命名软件包。这是一个骇人听闻的黑客行为,很可能与图书馆许可背道而驰。我也可以直接实现我需要的cookie东西,但是我很懒(尽管,显然,我想花我的精力解决这个问题,而不是使用已经拥有的接口(interface)实现cookie类)。
我觉得这是Square方面的错误,以及它们如何打包这些库/模块。由于他们非常关注Android,也许我是唯一想要在Java 9或更高版本上使用 okhttp-urlconnection 的人吗?因此,这个问题更多地是关于我是否应该将其作为缺陷提出来,也许我已经忽略了一些明显的问题。
最佳答案
OkHttp的错,我们可以为您解决。请打开一个跟踪错误,并提供指向此问题的链接。
我们将把这两个类移到新的包中。为了向后兼容,我们还需要将委派的实现留在后面。希望工具允许这样做!
JPMS具有此约束是非常糟糕的。我们已经修复了其他一些开源项目,但没有修复此项目。