The technical details: The plan is to ship the sqlline ubjerjar (sqlline provides an uberjar with all of its own dependencies shaded in) in the /lib directory, along with the log4j slf4j backend jar. sqlline.py and friends is to be updated to add those to the classpath.
Richard has this already up in https://github.com/apache/phoenix/pull/1239 On Wed, May 26, 2021 at 9:43 PM Josh Elser <els...@apache.org> wrote: > I think the idea is that we would include a sqlline jar with the Phoenix > distribution. Context: we had some grief where a sqlline upgrade caused > user pain because they were relying on specific output from sqlline. > > If we have the sqlline jar _not_ packaged inside phoenix-client, then > users can easily replace the version of sqlline which makes them happiest. > > While I agree with Istvan that #1 is the more "correct" option, I'm > worried about the impact of folks who rely on the phoenix-client.jar to > be a "batteries included" fat-jar. Removing sqlline from > phoenix-client-embedded is great, so I'd lean towards #2. > > We can see what adoption of phoenix-client-embedded looks like now that > we have it in releases. I imagine most folks haven't yet realized that > it's even an option that's available. > > On 5/26/21 1:16 PM, la...@apache.org wrote: > > Will sqlline still be part of the Phoenix "distribution"? Or will it > become a separate package to install? > > > > > > > > > > > > > > On Wednesday, May 26, 2021, 1:07:17 AM PDT, Istvan Toth < > st...@apache.org> wrote: > > > > > > > > > > > > Hi! > > > > The current purpose of the phoenix-client JAR is twofold: > > - It servers as a generic JDBC driver for embedding in applications > > - It also contains the sqlline library used by the sqlline.py script, as > > well as the slf4j log4j backend. > > - (It also contains a some Phoenix code and HBase libraries not necessary > > for a client, but we're already tracking that in different tickets) > > > > One major pain point is the slf4j backend, which makes phoenix-client > > incompatible with applications and libraries that do not use log4j 1.2 > as a > > backend, and kind of defeats the purpose of using slf4j in the first > place. > > phoenix-client-embedded solves this problem by removing the slf4j backend > > from Phoenix. > > > > In PHOENIX-6378 <https://issues.apache.org/jira/browse/PHOENIX-6378> we > aim > > to remove sqlline from the phoenix-client JAR, as it further cleans up > the > > classpath, and avoids locking phoenix to the sqlline version that it was > > built with. > > > > In Richard's current patch, we remove sqlline from > phoenix-client-embedded, > > and use that in the sqlline script. > > > > In our quest for a more useable phoenix-client, we can do two things now: > > > > 1. Remove both the slf4j backend, and sqlline from phoenix-client, and > > also drop phoenix-client-embedded as it would be the same as > phoenix-client > > 2. Remove sqlline from phoenix-client-embedded, and keep the current > > phoenix-client as backwards compatibility option > > > > I'd prefer the first option, but this is somewhat more disruptive than > the > > other. > > > > Please share your thoughts. Do you prefer option 1, 2, or something else > > entirely ? > > > > Istvan > > > -- *István Tóth* | Staff Software Engineer st...@cloudera.com <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> <https://www.cloudera.com/> ------------------------------
