[
https://issues.apache.org/jira/browse/HBASE-13517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14508314#comment-14508314
]
Elliott Clark commented on HBASE-13517:
---------------------------------------
This might work around that issue. However it's more intended to allow users
the freedom to choose which dependencies in their own servers without regard to
hold old or crufty our dependencies are. The other thing is it's pretty hard to
debug when there are incorrect versions on the classpath since the errors can
happen long after the process starts.
bq.Are we making trouble by pushing such an artifact to the maven repos?
It's a little more work for us, but I think for the end users it would be worth
it. ( The guava issue has bitten two different internal users separately in the
past week alone).
There are better long term solutions however all of them require hadoop to do
pretty drastic things, so I think this is the best solution for downstreamers
who need/want to use versions that don't line up with hadop and HBase
> Publish a client artifact with shaded dependencies
> --------------------------------------------------
>
> Key: HBASE-13517
> URL: https://issues.apache.org/jira/browse/HBASE-13517
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0, 1.1.0
> Reporter: Elliott Clark
> Assignee: Elliott Clark
> Fix For: 2.0.0, 1.1.0
>
> Attachments: HBASE-13517-v1.patch, HBASE-13517-v2.patch,
> HBASE-13517-v3.patch, HBASE-13517.patch
>
>
> Guava's moved on. Hadoop has not.
> Jackson moves whenever it feels like it.
> Protobuf moves with breaking point changes.
> While shading all of the time would break people that require the transitive
> dependencies for MR or other things. Lets provide an artifact with our
> dependencies shaded. Then users can have the choice to use the shaded version
> or the non-shaded version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
