Thanks for the super-detailed explanation and illustration.
I especially think you emphasized something we generally have not
considered: the end-user pinning a different version of a client lib, and
the fact that if we vendor the client lib they cannot change the version.
To me, that makes vendoring client libs kind of a deal-breaker. So I think:
a) yes, solved by vendored (already done)
b) leaving the IO's version of Guava on the classpath seems the only
solution, and end-user has to resolve
c) good point that in the not-on-API-surface case also, we can't really
tweak anything and we need the end-user to resolve
So the main action item is to remove the top-level Guava version and to let
IOs determine their Guava version, with resolution of diamond deps when
needed in test configurations.
On Wed, Mar 6, 2019 at 3:18 AM Michael Luckey <[EMAIL PROTECTED]> wrote: