So how is no shading better than this partial shading? You'd end up with the same conflicts, no?
As far as I know, a JDBC implementation exposes nothing outside java.sql.*. Anything else exposed by the shaded jar is probably a bug. Can you provide more details on what you're seeing, or -- better still -- file a JIRA? On Thu, Sep 15, 2016 at 11:45 AM, Marco Villalobos < [email protected]> wrote: > Not all of its dependencies are repackaged though, which leads to > class loading conflicts. When is that ever a good thing? > > On Thu, Sep 15, 2016 at 9:28 AM, Nick Dimiduk <[email protected]> wrote: > > Maybe I'm missing something, but... > > > > The whole point of providing a shaded client jar is to prevent exposing > > Phoenix implementation details to the applications that consume it -- > > effectively allowing people to manage their own dependencies. Using a > > shaded client jar means you don't have to worry about dependency conflict > > because by definition there's only one dependency: the shaded client. > What > > are you able to achieve now with, say, the 4.7.0 unshaded client that you > > cannot with the new 4.8.0 shaded client? > > > > Thanks for the explanation. > > -n > > > > On Thu, Sep 15, 2016 at 7:56 AM, Marco Villalobos < > [email protected] > >> wrote: > > > >> Good morning. > >> > >> I want to provide a module that provides the unshaded version of the > jdbc > >> client. > >> > >> This will allow people to manage their own dependencies without worry of > >> conflict. > >> > >> -Marco. > >> > >> > >> >
