>
> 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?
>> >
>>
>

Reply via email to