[
https://issues.apache.org/jira/browse/HBASE-17908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058650#comment-16058650
]
stack commented on HBASE-17908:
-------------------------------
Working on a patch that depends on new hbase-thirdparty project which bundles
up a couple of problematic libs into a fat jar and then offsets the libs so
they are at an offset of org.apache.hbase.thirdparty.shaded. Patch is mostly
changing imports and then some fixup of the differences between guava 12.0 and
22.0, the currently shipping version. Of note is that ReplicationEndpoint
implemented guava Service which has changed a good bit in 22.0. That makes this
a 'breaking' change though all RE implementations are marked audience Private.
This change will break stuff like they lily indexer. Need to talk to them about
it. Could depend on guava 12.0 since all internel refs will be to the relocated
guava 22.0 but that'd be awkward to message (use the internal guava everywhere
though the 'natural-seeming' com.google.guava is on your classpath). Lets not
do this unless we really have too. Can do in separate issue.
> Upgrade guava
> -------------
>
> Key: HBASE-17908
> URL: https://issues.apache.org/jira/browse/HBASE-17908
> Project: HBase
> Issue Type: Sub-task
> Components: dependencies
> Reporter: Balazs Meszaros
> Priority: Critical
> Fix For: 2.0.0
>
>
> Currently we are using guava 12.0.1, but the latest version is 21.0.
> Upgrading guava is always a hassle because it is not always backward
> compatible with itself.
> Currently I think there are to approaches:
> 1. Upgrade guava to the newest version (21.0) and shade it.
> 2. Upgrade guava to a version which does not break or builds (15.0).
> If we can update it, some dependencies should be removed:
> commons-collections, commons-codec, ...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
