Grpc

[elharo]

It's not immediately obvious why these two pom.xml files separately declare versions.

[pongad]

Wait sorry. I think we need to update GAX's gRPC as well right...?

[elharo]

Possibly. This is an experiment to see if it breaks. Not quite ready to commit to this yet. One thing I'm curious about is why we're setting these versions in multiple places.

[pongad]

@elharo I think it's because the api-grpc and cloud-clients don't share a parent. This might just be someting carried over from when they were in different repositories. @vam-google Can you comment?

[elharo]

Yes, that seems right. Should they share a parent? or perhaps each import a BOM that manages the dependencies for both?

[elharo]

Theoretically we shouldn't need to upgrade GAX at the same time since it's on 1.13.1 and 1.15.0 (minor version bump) is supposed to be backwards compatible with that. But I wouldn't bet heavily on it.

[vam-google]

@elharo, @pongadgoogle-api-grpc and google-cloud-clients have different group ids (com.google.api.grpc and com.google.cloud respectively). Putting those under same parent is against maven's naming conventions (i'm not even sure that it will compile/publish, or at least not output severe warnings in the console on build). This separation is historical (happened much earlier than grpc packages migration to google-cloud-java). It partially makes sense (since all the grpc packages are not necessarily about cloud). To adhere to maven naming convention the parent must be in group com.google but that is too generic (like defining a parent pom for the whole google under google-cloud-java).

So the current separation is by design. It is annoying to have to repeat same dependency multiple times, but unfortunately it is not the only place (there are many dependencies duplications, not only in this repo), so fixing it here will not fix the actual problem. How to fix that dependency duplication problem is actually a very complicated problem (out of scope here).

(one of the first googled stackoverflow links regarding parent-child groupId relation)

[elharo]

@vam-google Do you have a reference for not putting different group IDs under the same parent? Happy not to do it here, but it may be relevant for some PRs in other repos I'm looking at.

[vam-google]

When I was doing it I remember that putting those under same parent didn't really work (I'm not saying it did not compile, but it caused more problems than solved). As for the reference, the one, with pretty weak wording (describing it only as "A good way", not a "must") is in the maven documentation:

"A good way to determine the granularity of the groupId is to use the project structure. That is, if the current project is a multiple module project, it should append a new identifier to the parent's groupId. For example, org.apache.maven, org.apache.maven.plugins, org.apache.maven.reporting.

Notice, that children must share prefix, the only way for our case to share prefix is to have com.google group as a parent, which is too generic. Aslo there were other reasons to keep those separate (having common parent solves some problems, but also makes the whole project structure more monolithic).

[elharo]

Looks like the CI hung. Anyone happen to know how to force it to restart?

[garrettjonesgoogle]

@chingor13 how do we trigger Kokoro to run?

[chingor13]

We add the kokoro:force-run label and Kokoro will pick it up.

[chingor13]

LGTM, @garrettjonesgoogle can merge when gax is updated as well.

[garrettjonesgoogle]

It's fine to merge this before GAX