Skip to content

core, inprocess, util: move inprocess and util code into their own new artifacts grpc-inprocess and grpc-util#10362

Merged
sanjaypujare merged 7 commits into
grpc:masterfrom
sanjaypujare:java9-core-split
Jul 17, 2023
Merged

core, inprocess, util: move inprocess and util code into their own new artifacts grpc-inprocess and grpc-util#10362
sanjaypujare merged 7 commits into
grpc:masterfrom
sanjaypujare:java9-core-split

Conversation

@sanjaypujare

Copy link
Copy Markdown
Contributor

@sanjaypujare sanjaypujare requested a review from larry-safran July 9, 2023 19:00
@sanjaypujare

Copy link
Copy Markdown
Contributor Author

Thanks @larry-safran . Now waiting for @ejona86 's LGTM....

@sanjaypujare

sanjaypujare commented Jul 12, 2023

Copy link
Copy Markdown
Contributor Author

Gentle ping @ejona86 - waiting for your LGTM

@ejona86 ejona86 self-requested a review July 13, 2023 20:30
Comment thread core/BUILD.bazel

java_library(
name = "internal",
visibility = ["//visibility:public"],

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

internal should not be public. Why did you need this? It was already allowing subpackages.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -1,3 +1 @@
io.grpc.internal.PickFirstLoadBalancerProvider
io.grpc.util.SecretRoundRobinLoadBalancerProvider$Provider

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RR moving to grpc-util could definitely break users in a hard-to-diagnose way. I'm not sure how we want to handle this. Short-term we could have a runtimeDependency in grpc-core onto grpc-util.

That would mean we'd also want //inprocess in core_maven

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... Short-term we could have a runtimeDependency in grpc-core onto grpc-util.

Interesting. grpc-util has an api dependency on grpc-core so doing what you suggest makes the dependency circular (even with runtimeOnly dependency). Any ideas?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this is a blocker and needs to be resolved. So I'll wait for that before I address the remaining comments.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was aware that would be the case. But it should work. Are you saying it doesn't work?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I had tried it before I added the comment:

* What went wrong:
Circular dependency between the following tasks:
:grpc-core:checkUpperBoundDeps
+--- :grpc-core:jar
|    +--- :grpc-core:classes
|    |    \--- :grpc-core:compileJava
|    |         \--- :grpc-core:checkUpperBoundDeps (*)
|    \--- :grpc-core:compileJava (*)
\--- :grpc-util:jar
     +--- :grpc-util:classes
     |    \--- :grpc-util:compileJava
     |         +--- :grpc-core:compileJava (*)
     |         \--- :grpc-util:checkUpperBoundDeps
     |              +--- :grpc-core:jar (*)
     |              \--- :grpc-util:jar (*)
     \--- :grpc-util:compileJava (*)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been resolved

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi i just wanted to let you know that this did indeed break for us in a hard to diagnose way. Is there a correct way to upgrade this library so that it does not break? in general we use something like

ManagedChannelBuilder
            .forTarget(URL)
            .defaultLoadBalancingPolicy("round_robin")
            .usePlaintext()
            .build()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mdering "break" is not a helpful description. Please open a new issue and describe the error/problem you see when upgrading. You can link to this PR. For this specific change, it's also important whether you are shading/shadowing/making a fat jar.

Comment thread core/BUILD.bazel
)

java_library(
name = "inprocess",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leave a forwarding library in place. Keep name and visibility and have it export //inprocess. Ditto for util.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Comment thread inprocess/build.gradle Outdated
components.java.withVariantsFromConfiguration(configurations.testFixturesRuntimeElements) { skip() }


tasks.register("versionFile") {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep this in core. It is not needed in inprocess and util.

Comment thread inprocess/build.gradle Outdated
exclude 'io/grpc/inprocess/Internal*'
}

animalsniffer {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delete. There's no jmh.

Comment thread inprocess/build.gradle Outdated
testFixtures(project(':grpc-core'))
testImplementation libraries.guava.testlib

testRuntimeOnly project(':grpc-census')

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delete.

Comment thread repositories.bzl Outdated
"io.grpc:grpc-stub": "@io_grpc_grpc_java//stub",
"io.grpc:grpc-testing": "@io_grpc_grpc_java//testing",
"io.grpc:grpc-xds": "@io_grpc_grpc_java//xds:xds_maven",
"io.grpc:grpc-inprocess": "@io_grpc_grpc_java//inprocess",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sort these.

Comment thread rls/build.gradle Outdated
dependencies {
implementation project(':grpc-core'),
project(':grpc-protobuf'),
api project(':grpc-util')

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be an implementation dependency.

Comment thread util/BUILD.bazel Outdated
# with maven_install's override_targets. Should only be used as a dep for
# pre-compiled binaries on Maven Central.
java_library(
name = "util_maven",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no need to export //api from here, so delete the entire target. If it were needed, it should have been used from repositories.bzl

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Delete this file and use src/main/resources instead.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@ejona86 ejona86 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most of my earlier comments apply to util/build.gradle as well.

Comment thread grpclb/build.gradle Outdated

dependencies {
implementation project(':grpc-core'),
implementation project(':grpc-inprocess'),

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was it changed to depend on inprocess?

Comment thread util/build.gradle Outdated
dependencies {
api project(':grpc-core')

implementation libraries.gson,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why depend on gson?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without it the build of grpc-services fails:

* What went wrong:
Execution failed for task ':grpc-services:checkUpperBoundDeps'.
> Maven version skew: com.google.code.gson:gson (2.8.9 != 2.10.1) Bad version dependency path: [project ':grpc-services', com.google.protobuf:protobuf-java-util:3.22.3] Run './gradlew :grpc-services:dependencies --configuration runtimeClasspath' to diagnose

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And then running ./gradlew :grpc-services:dependencies --configuration runtimeClasspath (as suggested) gives me:

runtimeClasspath - Runtime classpath of source set 'main'.
...
+--- project :grpc-util
|    +--- project :grpc-core
|    |    +--- project :grpc-api (*)
|    |    +--- com.google.code.gson:gson:2.10.1 ===> v2.10.1 referenced
|    |    +--- com.google.android:annotations:4.1.1.4
|    |    +--- org.codehaus.mojo:animal-sniffer-annotations:1.23
|    |    +--- com.google.errorprone:error_prone_annotations:2.18.0
|    |    +--- com.google.guava:guava:32.0.1-android -> 32.0.1-jre (*)
|    |    +--- io.perfmark:perfmark-api:0.26.0
|    |    +--- project :grpc-context
|    |    |    \--- project :grpc-api (*)
|    |    \--- project :grpc-util (*)
|    +--- org.codehaus.mojo:animal-sniffer-annotations:1.23
|    \--- com.google.guava:guava:32.0.1-android -> 32.0.1-jre (*)
+--- com.google.protobuf:protobuf-java-util:3.22.3
|    +--- com.google.protobuf:protobuf-java:3.22.3
|    +--- com.google.code.findbugs:jsr305:3.0.2
|    +--- com.google.code.gson:gson:2.8.9 -> 2.10.1 ===> v2.8.9 referenced 
|    +--- com.google.errorprone:error_prone_annotations:2.11.0 -> 2.18.0
|    +--- com.google.guava:guava:31.1-jre -> 32.0.1-jre (*)
|    \--- com.google.j2objc:j2objc-annotations:1.3 -> 2.8
...

I can also fix it by making libraries.gson a runtimeOnly dependency of grpc-util and then add a comment describing why it is required?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can also fix it by making libraries.gson a runtimeOnly dependency of grpc-util and then add a comment describing why it is required?

Yes. Do that for forced upgrading to fix version skew.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already done with a comment

Comment thread util/build.gradle Outdated
Comment thread core/build.gradle Outdated
// force dependent jars to depend on latest grpc-context
runtimeOnly project(":grpc-context")
runtimeOnly project(":grpc-context"),
project(":grpc-util")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Include a comment that we depend on grpc-util to pull in RR

Comment thread core/build.gradle
@sanjaypujare sanjaypujare merged commit 0f5f07f into grpc:master Jul 17, 2023
@sanjaypujare sanjaypujare deleted the java9-core-split branch July 17, 2023 18:45

@ejona86 ejona86 left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Comment thread core/BUILD.bazel
":internal",
":util",
"//api",
"//inprocess",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should have exported //util, not //inprocess (to mirror core/build.gradle)

Comment thread util/build.gradle

implementation libraries.animalsniffer.annotations,
libraries.guava
runtimeOnly libraries.gson // to fix checkUpperBoundDeps error in services

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this should go in services.

jonatan-ivanov added a commit to micrometer-metrics/micrometer that referenced this pull request Sep 7, 2023
grpc-core does not contain the inprocess classes anymore,
they were moved out to io.grpc:grpc-inprocess
so we need to add it as a dependency.

See https://github.com/grpc/grpc-java/releases/tag/v1.58.0
See grpc/grpc-java#10362

Closes gh-4063
@github-actions github-actions Bot locked as resolved and limited conversation to collaborators Dec 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants