I'd prefer to rely on shading instead of making it as provided. As I
understand it, using the provided scope doesn't really help us any more
than a downstream project overriding the version of Guava Calcite
depends upon. If downstream projects provide their own version of Guava,
we have no guarantee that the provided version will satisfy our needs
(Guava has a tendency to remove APIs in the release after they've been
deprecated).
With my history in dealing with Hadoop and friends, I'm of the opinion
that we should not expose these dependencies to our downstream users at
all. Shade+relocate, downstream projects include whatever version of
Guava they'd like. If we want to make sure we keep the size of the jars
down, we can still provide non-shaded artifacts with the express
understanding that users will need to provide a specific version.
This recommendation also requires that we don't expose Guava classes via
any Calcite APIs (as we can't be 100% certain such classes won't disappear).
Julian Hyde wrote:
Michael Mior would like to upgrade Guava from 14 to 15 so that we can use
Cassandra 3.0. But I know some projects (e.g. Hive) depend on earlier versions.
So, how to please everyone?
I have logged
https://issues.apache.org/jira/browse/CALCITE-1111<https://issues.apache.org/jira/browse/CALCITE-1111>
and am suggesting solving the problem by making Guava what Maven calls a “provided”
dependency. Do you think that might work?
If this works, we might try the same approach with Jackson. (Jackson is
currently shaded in Avatica but not relocated.)
Julian
