[
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)
