For the avatica (client) jar, it's meant to be a single distributable
artifact, but I could see value in providing both a shaded and
non-shaded jar, letting the user decide which one they want.
It will force us to be much clearer about what the dependency needs of
the Avatica client are.
Ted Dunning wrote:
Frankly, just using provided scope and requiring version 2.* might be a
better course.
This would particularly be true if any of the Jackson classes are used in
any API's.
On Thu, Dec 10, 2015 at 5:17 PM, Josh Elser<[email protected]> wrote:
Hi Mike,
Yup, you're spot-on with relocation the classes. I only relocated the
protobuf classes because I had just added them. Didn't think to also do
that with the Jackson classes. Really, anything that gets shaded should be,
AFAIK. Want to open a JIRA issue?
As for updating Jackson, I'd have to look at the changelog. It's probably
going to be OK, but you never know what issues might sneak in when updating
the dependency. A JIRA issue for this would also be good.
Thanks for letting us know!
- Josh
Mike Hinchey wrote:
I'm have difficulty building my project which uses both calcite and
another
lib that uses a different version of fasterxml/jackson.
I found that avatica builds an uberjar, using mvn-shade to rename the
protobuf package, but also includes the jackson classes in the jar. This
is the case since 1.5.0, not before. Is that intentional?
Should the jackson packages also be renamed/shaded within avatica?
Incidentally, jackson 2.1.1 is from 2012. The latest stable release is
2.6.3. All tests pass with the new version.
Thanks,
Mike
