You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by Josh Elser <el...@apache.org> on 2020/03/25 19:01:51 UTC
[DISCUSS] client/server jar naming, post hbase-compat changes
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?
Re: [DISCUSS] client/server jar naming, post hbase-compat changes
Posted by Guanghao Zhang <zg...@gmail.com>.
>
> 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 <zg...@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 <el...@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?
>> >
>>
>
Re: [DISCUSS] client/server jar naming, post hbase-compat changes
Posted by Istvan Toth <st...@apache.org>.
Created https://issues.apache.org/jira/browse/PHOENIX-5808 to track this.
On Thu, Mar 26, 2020 at 6:59 PM Josh Elser <el...@apache.org> wrote:
> On 3/26/20 5:22 AM, Istvan Toth wrote:
> > On Thu, Mar 26, 2020 at 5:39 AM Guanghao Zhang <zg...@gmail.com>
> 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 assemblies (tar balls) for each HBase version,
> > and the assemblies only contain the shaded artifacts for the specific
> HBase
> > version that the assembly was built for.
> >
>
> Yes, as Istvan says. Sorry I was not more clear in my explanation :)
>
Re: [DISCUSS] client/server jar naming, post hbase-compat changes
Posted by Josh Elser <el...@apache.org>.
On 3/26/20 5:22 AM, Istvan Toth wrote:
> On Thu, Mar 26, 2020 at 5:39 AM Guanghao Zhang <zg...@gmail.com> 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 assemblies (tar balls) for each HBase version,
> and the assemblies only contain the shaded artifacts for the specific HBase
> version that the assembly was built for.
>
Yes, as Istvan says. Sorry I was not more clear in my explanation :)
Re: [DISCUSS] client/server jar naming, post hbase-compat changes
Posted by Istvan Toth <st...@apache.org>.
On Thu, Mar 26, 2020 at 5:39 AM Guanghao Zhang <zg...@gmail.com> 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 assemblies (tar balls) for each HBase version,
and the assemblies only contain the shaded artifacts for the specific HBase
version that the assembly was built for.
Re: [DISCUSS] client/server jar naming, post hbase-compat changes
Posted by Guanghao Zhang <zg...@gmail.com>.
>
> 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 <el...@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?
> >
>
Re: [DISCUSS] client/server jar naming, post hbase-compat changes
Posted by Istvan Toth <st...@apache.org>.
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 <el...@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?
>