Created https://issues.apache.org/jira/browse/PHOENIX-5808 to track this.
On Thu, Mar 26, 2020 at 6:59 PM Josh Elser wrote:
> On 3/26/20 5:22 AM, Istvan Toth wrote:
> > On Thu, Mar 26, 2020 at 5:39 AM Guanghao Zhang
> wrote:
> >
> >>
> >> I thought user still need to care about which hbase vers
On 3/26/20 5:22 AM, Istvan Toth wrote:
On Thu, Mar 26, 2020 at 5:39 AM Guanghao Zhang wrote:
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?
They do need to care when they are referencing maven ar
On Thu, Mar 26, 2020 at 5:39 AM Guanghao Zhang wrote:
>
> 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?
>
>
They do need to care when they are referencing maven artifacts.
However there are separate
>
> 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 于2020年3月26日周四 下午12:39写道:
> This would make dow
>
> 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.
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 versi
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 local