cyclic dependency issue in 1.58.0 (Bazel) #10576
Comments
|
I think inherently this error is a bug in https://github.com/bazelbuild/rules_jvm_external/ . What Bazel version are you using? I used this snippet in a WORKSPACE, and it seemed to work fine for me in Bazel 6.3.2: We do generally prefer/encourage building from source, like in our examples/WORKSPACE. I know that since #10217 the README has mentioned using artifacts from Maven. |
|
Doh, rules_jvm_version is what really matters. This is what we had in the WORKSPACE I tested in: |
|
I am using this looks like a bug in upstream https://repo1.maven.org/maven2/io/grpc/grpc-core/1.58.0/grpc-core-1.58.0.pom https://repo1.maven.org/maven2/io/grpc/grpc-util/1.58.0/grpc-util-1.58.0.pom |
|
If the POM itself are showing cyclic dependency , i am quite unsure how did work for you ? for example i have the following depdendencies in my bazel dependencies yaml config |
|
grpc-core has a runtime dependency on grpc-util. That's how it works. I'll note that neither Gradle nor Maven have a problem with it.
Unclear if that is Bazel version or rules_jvm_external. But it looks like rules_jvm_external didn't have a 4.2.2, so that must be the Bazel version. Bazel 4 isn't supported by anyone, to my knowledge. Because you are using an older Bazel, you are probably using an older rules_jvm_external. I suggest upgrading rules_jvm_external and reporting if that fixes the problem. I provided what I did to try and reproduce, and it seemed to be working, so it seems this is possibly as simple as "upgrade your tools and the problem is fixed." |
|
upgrading bazel is non trivial effort and requires coordination with another repo as well using storage 2.27.0 and grpc-java 1.56.1 works Can you please elaborate on why the rules_jvm_external could have been the issue , doesnt it generate the dependency list based on the POM ? it is unclear to me how we differentiate in the bazel depdendency list what is runtime vs compile time , they are just all included in dependency list |
What version did you upgrade from and to? If it was a version from the past year, I think you need to provide a reproduction example, as it doesn't reproduce for me. rules_jvm_external is what powers maven_install. It is the thing producing the error... (actually coursier is the component, but I think rules_jvm_external packages that dependency.)
Sure, but that shouldn't matter. You aren't specifying dependencies between those in the list. When you use a particular dependency, you'd use |
|
we internally use a forked Repo from rules_jvm_external |
|
I've reproduced it. The error wasn't in coursier but in Bazel itself. And in my earlier test I think I didn't trigger the right target during a build. With # rules_jvm_external boilerplate
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
RULES_JVM_EXTERNAL_TAG = "5.3"
RULES_JVM_EXTERNAL_SHA = "d31e369b854322ca5098ea12c69d7175ded971435e55c18dd9dd5f29cc5249ac"
http_archive(
name = "rules_jvm_external",
sha256 = RULES_JVM_EXTERNAL_SHA,
strip_prefix = "rules_jvm_external-%s" % RULES_JVM_EXTERNAL_TAG,
url = "https://github.com/bazelbuild/rules_jvm_external/releases/download/%s/rules_jvm_external-%s.tar.gz" % (RULES_JVM_EXTERNAL_TAG, RULES_JVM_EXTERNAL_TAG),
)
load("@rules_jvm_external//:repositories.bzl", "rules_jvm_external_deps")
rules_jvm_external_deps()
load("@rules_jvm_external//:setup.bzl", "rules_jvm_external_setup")
rules_jvm_external_setup()
# END rules_jvm_external boilerplate
load("@rules_jvm_external//:defs.bzl", "maven_install")
maven_install(
artifacts = [
"io.grpc:grpc-okhttp:1.58.0",
],
repositories = [
"https://repo.maven.apache.org/maven2/",
],
)Looking at the generated BUILD file, it doesn't use runtime_deps for the runtime-scoped: jvm_import(
name = "io_grpc_grpc_core",
jars = ["v1/https/repo.maven.apache.org/maven2/io/grpc/grpc-core/1.58.0/grpc-core-1.58.0.jar"],
deps = [
":com_google_android_annotations",
":com_google_code_gson_gson",
":com_google_errorprone_error_prone_annotations",
":com_google_guava_guava",
":io_grpc_grpc_api",
":io_grpc_grpc_context",
":io_grpc_grpc_util",
":io_perfmark_perfmark_api",
":org_codehaus_mojo_animal_sniffer_annotations",
],
tags = [
"maven_coordinates=io.grpc:grpc-core:1.58.0",
"maven_url=https://repo.maven.apache.org/maven2/io/grpc/grpc-core/1.58.0/grpc-core-1.58.0.jar",
],
visibility = ["//visibility:public"],
)And that's because jvm_import doesn't support runtime_deps, unlike java_import. So this is simply "rules_jvm_external is broken." A workaround looks to be to add an exclusion from grpc-core to grpc-util: load("@rules_jvm_external//:specs.bzl", "maven")
maven_install(
artifacts = [
"io.grpc:grpc-okhttp:1.58.0",
maven.artifact(
artifact = "grpc-core",
exclusions = [
"io.grpc:grpc-util",
],
group = "io.grpc",
version = "1.58.0",
),
],
repositories = [
"https://repo.maven.apache.org/maven2/",
],
)Note that grpc-util contains the round_robin load balancer, so you may need to depend on grpc-util manually. For "com.google.cloud:google-cloud-storage:2.27.0" in particular, this isn't a problem, because it depends on grpc-rls and grpc-services, both of which depend on grpc-util. dependencies {
implementation(platform("io.grpc:grpc-bom:1.58.0")) {
exclude group: "io.grpc", module: "grpc-util"
}
implementation "com.google.cloud:google-cloud-storage:2.27.0"
} |
|
I have just run into this as well while trying to bump gRPC from 1.54.1 to 1.58.0 in https://github.com/enola-dev/enola. Copy/pasting the suggested workaround above verbatim is giving me the following error; I'm looking into it: |
|
I initially struggled with how apply the workaround from grpc/grpc-java#10576 for my enola-dev/enola#295; hopefully this docs enhancement helps others later.
I initially struggled with how apply the workaround from grpc/grpc-java#10576 for my enola-dev/enola#295; hopefully this docs enhancement helps others later.
|
It appears that you were able to resolve the problems and upgrade to v1.58.0 |
Although basic usage of Gradle does not cause problems, there are Gradle APIs that don't work when there are cyclical dependencies. For example, This API is used not infrequently in Gradle plugins and this prevents consumers from upgrading their gRPC dependencies. I don't disagree that, ideally, build tools would handle cyclical dependencies appropriately. But this is often not the case and it feels preferable to avoid cyclical dependencies here if at all possible. |
ejona86
changed the title
|
@ejona86 as per this comment I'm still seeing this, reproducible, over in enola-dev/enola#390 as of right now, at @larry-safran would it be possible to re-open this issue? |
In enola-dev/enola#390 as of right now, at 5b62332 I'm now on
Might this be worth for you to report on
I'm trying to figure out how to do such an |
Done in enola-dev/enola@964e8a0, and seems to work! 🥇 Interestingly, it now still works after removing the exclusion with enola-dev/enola@2ec63f6... hm, curious. It may be because I "unified" those 2 separate Maven Installs? Anyway. Moving on! |
|
@vorburger Since it is working for you now, do you still wish this issue to be reopened? |
|
@larry-safran no, all good as-is; thanks for asking! |
|
@larry-safran may I suggest reopening this issue? The workaround in the patch mentioned above is basically not to use bazel modules, which is not really the Right Thing given that |
|
@ekohlwey, we aren't aware of any incompatibility with bzlmod, except you may need to upgrade rules_jvm_external because of a fixed bug: bazelbuild/rules_jvm_external#966 (comment) . It looks like you got a response from your rules_jvm_external issue for the exclusion syntax. |
Add the 'fake' dependency to grpc-netty instead of grpc-core. grpc-okhttp already depends on grpc-util and probably would be fine without round_robin on Android. There's not actually a circular dependency, but some tools can't handle the compile vs runtime distinction. Such tools are broken, but fixes have been slow and this approach works with no real downfalls. Works around grpc#10576 grpc#10701
Add the 'fake' dependency to grpc-netty instead of grpc-core. grpc-okhttp already depends on grpc-util and probably would be fine without round_robin on Android. There's not actually a circular dependency, but some tools can't handle the compile vs runtime distinction. Such tools are broken, but fixes have been slow and this approach works with no real downfalls. Works around #10576 #10701
Add the 'fake' dependency to grpc-netty instead of grpc-core. grpc-okhttp already depends on grpc-util and probably would be fine without round_robin on Android. There's not actually a circular dependency, but some tools can't handle the compile vs runtime distinction. Such tools are broken, but fixes have been slow and this approach works with no real downfalls. Works around grpc#10576 grpc#10701
Add the 'fake' dependency to grpc-netty instead of grpc-core. grpc-okhttp already depends on grpc-util and probably would be fine without round_robin on Android. There's not actually a circular dependency, but some tools can't handle the compile vs runtime distinction. Such tools are broken, but fixes have been slow and this approach works with no real downfalls. Works around #10576 #10701
What version of gRPC-Java are you using?
1.58.0
What is your environment?
jdk 11, bazel
What did you expect to see?
succesful compilation
What did you see instead?
compilation error
Steps to reproduce the bug
cloud storage 2.27.0
using gcs cloud storage 2.27.0 and grpc-java 1.58.0
OR
cyclic depdendency issue
If i use an older version of gfprc-java 1.56.0 or older then
noSuchMethodError
"java.lang.NoSuchMethodError: 'void io.grpc.internal.AbstractManagedChannelImplBuilder.(java.lang.String)'"
=> java.lang.NoSuchMethodError: 'void io.grpc.internal.AbstractManagedChannelImplBuilder.(java.lang.String)'
I saw that the particular method has been removed in 1.58.0
The text was updated successfully, but these errors were encountered: