Kevin Risden wrote:
I guess that's really my question (I just needed to think about it more):
what artifacts should we not include when we shade? Would your life have
been better if we expected slf4j-api to be provided and not shaded?
Part of me feels that none of the dependencies should be shaded for the
avatica artifact. This would give avatica-server and others artifacts
depending on avatica the ability to exclude any dependencies they want.
Having explicit control over what dependencies can and can't be excluded is
nice.
Maybe an avatica-client artifact that has the dependencies shaded would be
nice since it would allow clients to connect with a single jar.
Well, I know (because I've had this talk specifically with him) that
Julian included the dependencies with Avatica (client) because he wanted
to have a single artifact that downstream users could pull in.
Since then, what has gone into this JAR has grown (slf4j being one
notable additional).
I think this would get the best of both worlds (avatica without shaded,
avatica-client that is shaded). I don't know what impact this would have on
downstream users of Avatica though.
That's going to be the pain in doing this. It's would be weird to start
providing "avatica-nonshaded.jar" (because avatica.jar is expected to be
shaded). I'm starting to lean that this should be a 2.0.0 change. Not
implying that it needs to be sufficiently in the future, just that the
version string needs to have a "major" number increment.
