phoenix-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-5213) Phoenix-client improvements: add more relocations, exclude log binding, change naming
Date Wed, 27 Mar 2019 15:33:00 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-5213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802934#comment-16802934
] 

Josh Elser commented on PHOENIX-5213:
-------------------------------------

{quote}
3) Changing the jar naming from phoenix-[version]-client.jar to phoenix-client-[version].jar
The reason for this is that there is no way, AFAIK, to change the naming convention in maven's
repo. You can change the jar name locally, but when it gets installed to the repo, it always
has to follow the artfiactname-version naming convention. To avoid confusion of having two
separate jar file names, I propose we just change it to Maven's convention so we can publish
releases of phoenix-client.
{quote}

This doesn't sound correct to me. The reason that this shaded jar is not attached is: https://github.com/apache/phoenix/blob/4.x-HBase-1.4/phoenix-client/pom.xml#L95.
Granted, the renaming makes it harder to use, but not a show-stopper :). IMO, as long as we
keep a copy/symlink of the phoenix-client jar in PHOENIX_HOME with the old name, we're good.
We can tell users how we'd like them to use it going forward.

bq. 2) Exclude the slf4j-log4j12 binding. Apparently this isn't pulled in directly from phoenix-core
itself, but transitively from other projects. It's generally considered best practice to not
impose a log binding on downstream projects. The slf4j-log4j12 jar will still be in the phoenix
tarball's /lib folder.

With BI tools, webservers, appservers, etc in mind: is having a jar that doesn't have an slf4j
impl provided going to cause them headache? Can we reasonably assume that folks will be capable
of providing this? If not, does it make sense to have two artifacts?

With this change today, we would need to modify our scripts (sqlline.py, psql.py, etc) to
also add slf4j-log4j12.jar to the classpath. I don't see that in your patch.

For the {{com.sun}} and {{javax}} relocations, I don't have any understanding in the forefront
of my head as to whether or not moving them will be a problem. I assume they weren't moved
the first time for a reason. Not sure if [~sergey.soldatov] remembers. Maybe [~busbey] knows
from his HBase-shaded-jars work and can drop a knowledge bomb on us?

bq. 4) Create a source jar for phoenix-client.

What's your thinking in creating this? Redistributing a source artifact for a "custom binary
jar" seems odd to me, especially when we don't control a vast majority of the classes we're
including in this jar.

bq. 5) Create a dependency-reduced pom, so that the client can be used directly in downstream
projects without having to exclude transitive artifacts.

+1

> Phoenix-client improvements:  add more relocations, exclude log binding, change naming
> --------------------------------------------------------------------------------------
>
>                 Key: PHOENIX-5213
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-5213
>             Project: Phoenix
>          Issue Type: Improvement
>    Affects Versions: 5.0.0, 4.15.0
>            Reporter: Vincent Poon
>            Assignee: Vincent Poon
>            Priority: Major
>         Attachments: PHOENIX-5213.4.x-HBase-1.4.v1.patch
>
>
> To make the existing phoenix-client, I'm proposing the following changes:
> 1)  Add additional relocations of some packages
> 2)  Exclude the slf4j-log4j12 binding.  Apparently this isn't pulled in directly from
phoenix-core itself, but transitively from other projects.  It's generally considered best
practice to not impose a log binding on downstream projects.  The slf4j-log4j12 jar will still
be in the phoenix tarball's /lib folder.
> 3)  Changing the jar naming from phoenix\-\[version\]\-client.jar to phoenix-client-\[version\].jar
> The reason for this is that there is no way, AFAIK, to change the naming convention in
maven's repo.  You can change the jar name locally, but when it gets installed to the repo,
it always has to follow the artfiactname-version naming convention.  To avoid confusion of
having two separate jar file names, I propose we just change it to Maven's convention so we
can publish releases of phoenix-client.
> 4)  Create a source jar for phoenix-client.
> 5)  Create a dependency-reduced pom, so that the client can be used directly in downstream
projects without having to exclude transitive artifacts.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message