Yes, based on Josh's comments we're currently planning to with #2 1. Remove sqlline et al from phoenix-client-embedded 2. Leave phoenix-client unchanged 3. Provide an uber sqlline jar, for use with sqlline.py. , and switch sqlline.py to phoenix-client-embdedded
Istvan. On Thu, May 27, 2021 at 9:19 PM la...@apache.org <la...@apache.org> wrote: > - User > > I see, make sense. So if I understand this correctly then: > > 1. Remove sqlline et al from phoenix-client > 2. Remove phoenix-client embedded (since it is now the same as > phoenix-client) > 3. Provide an uber sqlline jar, for use with sqlline.py. > > i.e. option #1? > > PR 1239 seems to keep the phoenix-client jar, though. Which is option #2 > below. > > -- Lars > > On Wednesday, May 26, 2021, 9:36:30 PM PDT, Istvan Toth < > st...@cloudera.com> wrote: > > > > > > 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 > > > ________________________________ > > -- *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/> ------------------------------
