gax: cannot compile with references to SNAPSHOT of `api-common`

[diegomarquezp]

Local development of gax may fail if we are working with a SNAPSHOT of api-common (i.e. bazel build //gax:.... Maven installs work properly

This is because of dependencies.properties of gax pointing to an old released version. If we change this version locally to our working snapshot, the bazel job will fail to find the snapshot because it only fetches from public servers.

This may cause problems with dependencies other than api-common

edit: adding info from a personal investigation (it references the outdated showcase bazel workflow)

Versions declared in the dependencies properties need to be available in the specified repositories. Inspecting the source of jvm_maven_import_external shows it doesn’t fall back to local servers as the maven command would do. It rather converts artifact coordinates into jar urls to be downloaded from the specified servers

Possible solutions

Try to remove api-common from Bazel files, e.g. in java_gapic.bzl

Since gapic-generator-java is now released as a jar with its own dependencies, it may be redundant to manually list dependencies such as common-protos or api-common

Use maven_install (example) with previous snapshot installed

This rule takes advantage of the availability of local repositories as an option. We would have to run mvn install on the whole repository to have local snapshots available. This doesn’t solve the problem of having a dependencies file in sync with the actual contents of the poms across the repo. If we have to go with this approach, use release-please to manage the version of api-common.

[diegomarquezp]

cc: @blakeli0 @JoeWang1127 @suztomo We may want to leave this as an item for the hermetic build

[suztomo]

We may want to leave this as an item for the hermetic build

Sounds good to me.

it only fetches from public servers

What is "it"? Can you add an URL of its document that states so?

[diegomarquezp]

@suztomo I expanded the issue description with some findings of mine, plus I clarified what exactly fails to fetch the SNAPSHOT (the bazel resolution of dependencies)

[suztomo]

Thank you. jvm_maven_import_external is old one. maven_install is better.

[blakeli0]

This is a valid issue but it is a niche use case. When developing locally, we can use Maven instead. For self-service client, they should always use a released version. Closing as not planned.