[
https://issues.apache.org/jira/browse/PHOENIX-7141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793601#comment-17793601
]
Istvan Toth commented on PHOENIX-7141:
--------------------------------------
Unshaded packages:
com.beust: coming from omid, see OMID-267
io.netty: coming from the HA curator -> zk -> netty
javax.inject: coming form omid, I think we can safely relocate it
tables: we are shading this in client, I see no reaon not do the same in server
org.checkerframework: Seems to be an interaction between checker-qual coming
via hadoop-common -> guava, and
hbase-server -> caffeine
org.codehaus.mojo.animalsniffer: TBD
org.HdrHistogram : TBD
org.yaml.snakeyaml: TBD
org.apache.commons.configuration: TBD
org.apache.commons.configuration2: TBD
org.apache.commons.csv: TBD
org.apache.commons.csv: Known to be unrelocatable
org.apache.statemachine: TBD
This is quite a lot.
I wonder if we should just cut our losses, and switch phoenix-server to the
same shading setup used by by the client JARs, instead of playing whack-a-mole
as new dependencies crop up.
> hbase-server shading problems
> -----------------------------
>
> Key: PHOENIX-7141
> URL: https://issues.apache.org/jira/browse/PHOENIX-7141
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Reporter: Istvan Toth
> Priority: Blocker
>
> HBase-server is different from the rest of the shaded artifacts in that it it
> doesn't shade packages by default.
> As new dependencies were added to Phoenix, we were left with an hbase-server
> jar which includes unshaded libraries which potentially conflict with the
> hbase server classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
