Can someone please log a JIRA case for this? I have trouble keeping up with the discussion about which combination(s) of shaded & included libraries work for everyone. So I think in the short term the solution will be a bug-fix-branch with a hacked POM that produces what Kevin wants. Then we can figure out whether we can or want to include it in the POM on the master branch, say by means of profiles, and which of those combinations we push to Maven central when we make a release.
Julian > On May 2, 2016, at 8:16 AM, Josh Elser <[email protected]> wrote: > > Kevin Risden wrote: >> On Mon, May 2, 2016 at 10:00 AM, Josh Elser<[email protected]> wrote: >> >>> 1) A fully-shaded avatica client jar >>> 2) A non-shaded avatica client jar >>> 2a) An example project which shows how you can build your own shaded >>> artifact for your own purposes >>> >> >> Yea exactly :) I think we are on the same page now. I've read that Elastic >> blog post and they came to basically the same conclusions. I have no >> problem building a shaded artifact myself, but that is impossible when the >> artifact is already shaded. >> >> Here is a thought on how to accomplish this without drastically changing >> the avatica artifact. >> >> 1. Add a avatica-commons artifact that isn't shaded (that is the same as >> the avatica artifact). >> 2. avatica-server to avatica-commons >> 3. Point avatica to avatica-commons and keep it shaded. >> > > Sure, that'd be one way to approach it for 1.8.0 -- it shouldn't hurt anyone > from 1.7 and earlier. > > We really need to solidify an API for Avatica and just defer to SemVer for > guidance in the future, but I don't think that will happen until a 2.0.0 (and > this doesn't negatively impact us in that eventuality). > > Thanks for the positive discussion.
