I'm all for having a shaded version of the dependencies as long as consumers can choose whether or not they want to use the shaded version. Having a bunch of copies of common dependencies like Guava, Jackson, Protobuf, Netty, etc can make distribution tarballs for other projects massive.
On Mon, Feb 29, 2016 at 8:39 PM, Josh Elser <[email protected]> wrote: > 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 >> >> >>
