[
https://issues.apache.org/jira/browse/PHOENIX-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232595#comment-15232595
]
Sergey Soldatov commented on PHOENIX-2535:
------------------------------------------
[~elserj]
{quote}
Why make this change in phoenix-assembly/pom.xml? It seems like you're just
working around Maven wanting to create a jar then. If you set this to pom,
AFAIUI, that should not be trying to create any JAR for the module.
{quote}
Actually not. If set it to pom - it's just create a pom file. The only way I
have found to disable it - set a non existing phase for {{maven-jar-plugin}}
{quote}
Is there a reason why you aren't putting JARs generated by a module within that
module's target/ directory? This is really confusing to see in practice "I
built this module. Where the heck are the artifacts?"
{quote}
{{phoenix-assembly}} is generating tarball exactly at the {{target}} directory.
All this stuff is related to the relative path of jars in this tarball.
{quote}
Might be a bit more concise to make a property instead of repeating the shaded
relocation prefix. E.g.
<shaded.location>org.apache.phoenix.shaded</shaded.location> and then
<shadedPattern>${shaded.location}.com.fasterxml</shadedPattern>. Is this more
concise?
{quote}
sounds reasonable. will do that.
{quote}
This looks unnecessary. The maven-shade-plugin should already be defined in
pluginManagement in /pom.xml.
{quote}
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.
{quote}
I'm surprised to see phoenix-server and phoenix-server-client in this list. My
initial thought was that phoenix-client would be a shaded jar for the thick
driver. Either way, neither thick or thin driver will need phoenix-server.
{quote}
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.
{quote}
I hate to be the bearer of bad news, but these are most likely not meeting ASF
licensing requirements. For every bundled jar that Phoenix ships in a shaded
jar, we're going to have to
Copy any NOTICE text into a NOTICE file in the shaded jar
Copy necessary license and copyright information for non-ASLv2 licensed jars
into a LICENSE file in the shaded jar.
Yes, this will be horrible, but it is required.
{quote}
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:
{noformat}
META-INF//license:
total 176
-rw-r--r-- 1 ssoldatov staff 1592 Apr 7 23:41 LICENSE.base64.txt
-rw-r--r-- 1 ssoldatov staff 10174 Apr 7 23:41 LICENSE.commons-logging.txt
-rw-r--r-- 1 ssoldatov staff 10174 Apr 7 23:41 LICENSE.felix.txt
-rw-r--r-- 1 ssoldatov staff 26441 Apr 7 23:41 LICENSE.jboss-logging.txt
-rw-r--r-- 1 ssoldatov staff 1592 Apr 7 23:41 LICENSE.jsr166y.txt
-rw-r--r-- 1 ssoldatov staff 1465 Apr 7 23:41 LICENSE.jzlib.txt
-rw-r--r-- 1 ssoldatov staff 10174 Apr 7 23:41 LICENSE.log4j.txt
-rw-r--r-- 1 ssoldatov staff 1732 Apr 7 23:41 LICENSE.protobuf.txt
-rw-r--r-- 1 ssoldatov staff 1203 Apr 7 23:41 LICENSE.slf4j.txt
-rw-r--r-- 1 ssoldatov staff 1598 Apr 7 23:41 LICENSE.webbit.txt
{noformat}
And we don't have it in the current client jar :)
> 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)
