> > 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.
+1 for remove the useless unshaded client and server JAR. > Guanghao Zhang <zghao...@gmail.com> 于2020年3月26日周四 下午12:39写道： > 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? >> > >> >
