scope of dependency com.google.protobuf:protobuf-java-util become runtime from compile

[alex-lx]

What version of gRPC-Java are you using?

1.32.1

What is your environment?

irrelevant

What did you expect to see?

io.grpc:grpc-services depends on com.google.protobuf:protobuf-java-util with compile scope as it did before(e.g. version 1.28.0)

What did you see instead?

io.grpc:grpc-services depends on com.google.protobuf:protobuf-java-util with runtime scope

Steps to reproduce the bug

Compare the following two pom:
https://repo1.maven.org/maven2/io/grpc/grpc-services/1.32.1/grpc-services-1.32.1.pom
https://repo1.maven.org/maven2/io/grpc/grpc-services/1.28.0/grpc-services-1.28.0.pom

[sanjaypujare]

But what problem is this change causing you?

[voidzcy]

This is the result of migrating to Gradle java-library plugin. #7001 changed it from compile to implementation. With the java-library plugin, implementation dependencies are shown as runtime scoped in POM.

This change is intended, we do not want to leak protobuf-java-util to consuming projects' classpath. If your project needs it, you should add it to your project dependencies explicitly.

[alex-lx]

@sanjaypujare After change our grpc-services to the newer version, it can't compile because of lack of class.

@voidzcy I totally understand what's happened, and I had update our project dependencies to make things work, but I think the change that making some exposed API(though they're not written by you) hidden should be considered as a incompatible breaking because it breaks the client build. it seems to even not mentioned in the release note :-)

[ejona86]

In no way should this be construed to be a breaking change. Since protobuf-java-util was an internal dependency, nothing requires that gRPC continue depending on it. Since the problem only occurs when upgrading your dependencies, the appropriate action is to add an explicit dependency to protobuf-java-util at the same time.

[alex-lx]

Yes, protobuf-java-util should be an internal dependency, however it was exposed to the user as a transitive dependency for some reason. It seems hard to me to tell is a transitive dependency an API, but on the view of a library user, it does break our build(though it can be fixed very easy).

Open this issue not meant to ask your guys to modify something but a mention for whom might meet this problem.

[ejona86]

it does break our build

It did not break your build by itself. You changed your build to put it into an inconsistent state. I hit this point hard because "break the build" is a very bad thing to happen and we take very seriously, but this is much more innocent as it only broke your computer and is trivially resolved before submitting your version-updating change.

[ejona86]

It's the difference between "OMG things are on fire!" and "oh, that's annoying."