Note: Until supported, there is a workaround.
With OkHttp3 4.x on the build classpath (buildSrc, build-conventions, ...) and the (closed source) objectbox-gradle-plugin being on the same classpath as well, custom task code that utilizes OkHttp3 4.x APIs will fail on runtime with exceptions like
java.lang.NoClassDefFoundError: Could not initialize class okhttp3.internal.Util
or alternatively
java.lang.NoSuchFieldError: Companion
This seems to be the reason because somehow an old OkHttp3 3.x version lands on the same classpath (which I cannot see anywhere, neither through ./gradlew buildEnvironment nor by looking at the printed classpaths from my Gradle's --debug run) and this OkHttp3 3.x version is still written in Java, not knowing anything of the 4.x Kotlin rewrite of the OkHttp team. In essence, a OkHttp3 4.x Kotlin API call to some of the extension functions in okhttp3.internal.Util fails to find the Companion object if the OkHttp3 3.x version of the same okhttp3.internal.Util class is in the classpath.
As weird and confusing this all sounds, I could fix my classpath issue by explicitely excluding the okio-1.x dependency from the objectbox-gradle-plugin and adding a 2.x binary-compatible version, like so:
classpath("io.objectbox:objectbox-gradle-plugin:2.9.0") {
exclude group: "com.squareup.okio"
}
classpath "com.squareup.okio:okio:2.10.0"
I don't actually know whats going on in objectbox-gradle-plugin as it is proprietary and I don't even know if there is anything Objectbox could do (except for updating to a newer okio / okhttp), but I still wanted to have this issue being documented (and googleable) somewhere.
You may want to close this issue.
Note: Until supported, there is a workaround.
With OkHttp3 4.x on the build classpath (
buildSrc,build-conventions, ...) and the (closed source)objectbox-gradle-pluginbeing on the same classpath as well, custom task code that utilizes OkHttp3 4.x APIs will fail on runtime with exceptions likeor alternatively
This seems to be the reason because somehow an old OkHttp3 3.x version lands on the same classpath (which I cannot see anywhere, neither through
./gradlew buildEnvironmentnor by looking at the printed classpaths from my Gradle's--debugrun) and this OkHttp3 3.x version is still written in Java, not knowing anything of the 4.x Kotlin rewrite of the OkHttp team. In essence, a OkHttp3 4.x Kotlin API call to some of the extension functions inokhttp3.internal.Utilfails to find theCompanionobject if the OkHttp3 3.x version of the sameokhttp3.internal.Utilclass is in the classpath.As weird and confusing this all sounds, I could fix my classpath issue by explicitely excluding the
okio-1.xdependency from theobjectbox-gradle-pluginand adding a 2.x binary-compatible version, like so:I don't actually know whats going on in
objectbox-gradle-pluginas it is proprietary and I don't even know if there is anything Objectbox could do (except for updating to a newer okio / okhttp), but I still wanted to have this issue being documented (and googleable) somewhere.You may want to close this issue.