If someone is using BigTableIO with bigtable-client-core then having
BigTableIO and bigtable-client-core both depend on Guava 26.0 is fine,
right? Specifically, a user of BigTableIO after
https://github.com/apache/beam/pull/7957 will still have non-vendored Guava
on the classpath due to the transitive deps of bigtable-client-core.

In any case it seems very wrong for the Beam root project to manage the
version of Guava in BigTableIO since the whole point is to be compatible
with bigtable-client-core. Would it work to delete our pinned Guava version
[1] and chase down all the places it breaks, moving Guava dependencies
local to places where an IO or extension must use it for interop? Then you
don't need adapters.

In both of the above approaches, diamond dependency problems between IOs
are quite possible.

I don't know if we can do better. For example, producing a
bigtable-client-core where we have relocated Guava internally and using
that could really be an interop nightmare as things that look like the same
type would not be. Less likely to be broken would be bigtable-client-core
entirely relocated and vendored, but generally IO connectors exchange
objects with users and the users would have to use the relocated versions,
so that's gross.

Kenn

[1]
https://github.com/apache/beam/blob/master/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy#L353
On Thu, Feb 28, 2019 at 2:29 AM Gleb Kanterov <[EMAIL PROTECTED]> wrote: