> > This would make downstream applications/users a little more simple -- > not having to worry about the HBase version in use (since their concerns > are what version of Phoenix is being used, instead). We could even > introduce non-Phoenix-versioned symlinks for these jars (e.g. > phoenix-client.jar and phoenix-server.jar).
I thought user still need to care about which hbase version in use? phoenix-server-xxx-hbase-2.1.jar not worked with hbase 2.2.x cluster now? > > Istvan Toth <st...@apache.org> 于2020年3月26日周四 上午5:09写道： > Hi! > > According to comments in the POMs, the phoenix-VERSION-client/server.jar > symlinks are deprecated. (The symlinks were already there BTW, I just > updated their targets) > I kind of agree with the deprecation, as permuting the components of the > jar name to distinguish the shaded and non-shaded versions feels unintitive > and error-prone. > > The phoenix-xx-VERSION.jars were meant to be the unshaded JARs. However, > that doesn't make sense for the client and server artifacts, as those are > just shaded views of core. > > Removing the useless unshaded client and server JAR maven artifacts would > free up those names, and we could create both symlinks in the assembly that > you suggest. > > This would also mean that maven wouldn't return a useless artifact for > phoenix-client and phoenix-server without classifiers, which would also be > one less unpleasant surprise to users. > > So the user could use the canonical maven artifact filename, or one of the > two (or three if we keep the deprecate old name) symlinks from the > assembly. > If she wanted to use an artifact from artifact, she'd have to specify the > hbase version as classifier to get the correct client. (this doesn't > change) > > The same naming solution (or whatever we agree on) should be extended to > PQS and connectors as well. > > On Wed, Mar 25, 2020 at 8:01 PM Josh Elser <els...@apache.org> wrote: > > > Background: IstvanT has done a lot of really great work to clean up the > > HBase 2.x compatibility issues for us. This lets us move away from the > > HBase-version-tagged releases of Phoenix (e.g. HBase-1.3, HBase-1.4, > > etc), and keep a single branch which can build all of these. > > > > Building master locally, I noticed the following in my tarball, > > specifically the jars > > > > <snip> > > phoenix-5.1.0-SNAPSHOT-hbase-2.2-client.jar -> > > phoenix-client-5.1.0-SNAPSHOT-hbase-2.2.jar > > phoenix-5.1.0-SNAPSHOT-hbase-2.2-server.jar > > phoenix-5.1.0-SNAPSHOT-server.jar > > phoenix-client-5.1.0-SNAPSHOT-hbase-2.2.jar > > </snip> > > > > I think there are two things happening here. One is that the > > phoenix-5.1.0-SNAPSHOT-server.jar is "empty" -- it's not the shaded > > server jar, but the hbase-2.2-server.jar is the correct jar. I think > > this is just a bug (you agree, Istvan?) > > > > The other thing I notice is that it feels like Istvan was try to > > simplify some things via symlinks. My feeling was that we could take > > this a step further. What if, instead of just having "hbase-x.y" named > > jars, we give symlinked jars as well. Creating something like... > > > > <snip> > > phoenix-5.1.0-SNAPSHOT-client.jar -> > > phoenix-client-5.1.0-SNAPSHOT-hbase-2.2-client.jar > > phoenix-client-5.1.0-SNAPSHOT-hbase-2.2-client.jar > > phoenix-5.1.0-SNAPSHOT-server.jar -> > > phoenix-server-5.1.0-SNAPSHOT-hbase-2.2-server.jar > > phoenix-server-5.1.0-SNAPSHOT-hbase-2.2-server.jar > > </snip> > > > > This would make downstream applications/users a little more simple -- > > not having to worry about the HBase version in use (since their concerns > > are what version of Phoenix is being used, instead). We could even > > introduce non-Phoenix-versioned symlinks for these jars (e.g. > > phoenix-client.jar and phoenix-server.jar). I think this also moves us a > > little closer to what we used to have. > > > > Sounds like a good idea to others? > > >
