phoenix-dev 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-2535) Create shaded clients (thin + thick)
Date Fri, 08 Apr 2016 18:20:25 GMT

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

Josh Elser commented on PHOENIX-2535:
-------------------------------------

bq. phoenix-assembly is generating tarball exactly at the target directory. All this stuff
is related to the relative path of jars in this tarball. 

Oh, that's my bad. I totally misread the assembly descriptor. Thanks for clarifying :)

bq. I don't know whether it's a maven-assembly-plugin specific feature or just a bug there,
but if we remove those dependencies it will not collect the jar dependencies. 

This was about the comment above, specifying the maven-shade-plugin in dependencyManagement.
Sorry for the confusion.

bq. Well, that was in the original pom.xml at phoenix-assembly which was producing client
jar, so the client had query server as well as calcite inside. I will get rid of it. 

Ok. Yeah, if we're doing things correctly, the client should never have to have the phoenix-\[query\]server
jar's classes. Regarding the thin client jar now, we do have a shaded artifact ({{phoenix-server-client/target/phoenix-4.8.0-HBase-1.1-SNAPSHOT-thin-client.jar}}),
but the shaded classes aren't relocated. That was the other half of my question -- did I miss
you doing that in your patch? I think that was in the original spirit of the JIRA issue's
title.

bq. And that's exactly that those transforms are doing (or supposed to do). At least for licenses
in client jar it creates a directory META-INF/license with all non ASF license files like:
bq. And we don't have it in the current client jar

Ok. Hopefully this isn't too bad (I'm not sure if these have been looked at closely before).
Not all people will bundle a LICENSE and NOTICE inside of their jar. Sadly, we get screwed
by this. After we get a final patch, I can run through a build and step through each dependency
to make sure we're covered. Don't need to hold up your patch for that work (but we should
make sure it's kosher before making the next release).

(and because I forgot to say it initially) Great work on this. This will be a big improvement.

bq. Once the dust settles here, it would be great to re-evaluate publishing client jars to
maven central. It's a real PITA to tell folks doing maven dev to drop a jar into their resources
manually.

*huge* +1 to this one, Nick. 

> Create shaded clients (thin + thick) 
> -------------------------------------
>
>                 Key: PHOENIX-2535
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2535
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: Sergey Soldatov
>             Fix For: 4.8.0
>
>         Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, PHOENIX-2535-3.patch,
PHOENIX-2535-4.patch, PHOENIX-2535-5.patch
>
>
> Having shaded client artifacts helps greatly in minimizing the dependency conflicts at
the run time. We are seeing more of Phoenix JDBC client being used in Storm topologies and
other settings where guava versions become a problem. 
> I think we can do a parallel artifact for the thick client with shaded dependencies and
also using shaded hbase. For thin client, maybe shading should be the default since it is
new? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message