Is it reasonable to have a maven profile that uses jackson as “provided”[1] rather than shading? This would not be the default — the default would be continue to use a shaded version of jackson (relocated to org.apache.calcite.jackson, as Josh suggests) — but folks looking to embed calcite/avatica in a container might appreciate a lighter weight option.
Julian [1] http://stackoverflow.com/questions/6646959/difference-between-maven-scope-compile-and-provided-for-jar-packaging <http://stackoverflow.com/questions/6646959/difference-between-maven-scope-compile-and-provided-for-jar-packaging> > On Feb 26, 2016, at 10:03 AM, Josh Elser <[email protected]> wrote: > > Hi Kai, > > Avatica includes Jackson for the JSON parser (one of the serialization > mechanisms that Avatica uses). The Avatica client is designed to be a > single-artifact to make deployments for users very simple. > > That being said, since we're shading in Jackson, we should relocate it to > avoid problems for you downstream in Calcite "proper". Want to open a JIRA > issue? Thanks for bringing it up. > > - Josh > > Kai Gülzau wrote: >> Hi *, >> >> what’s the reason for including the whole Jackson jar inside the avatica jar? >> We are just using the calcite sql parser and are using a newer version of >> Jackson as included in avatica. >> >> As a result we can’t use the newer functionality of Jackson since the >> included version is used :-\ >> >> From my point of view it doesn’t make sense to include Jackson (with the >> normal package path) when it is also a compile dependency… >> >> >> When I have read it correctly in an older post >> “When we come to consensus on shading that could be another JIRA case.” >> It time to open a JIRA case? >> >> >> Regards, >> >> Kai
