It seems like Elasticsearch had similar problems: https://www.elastic.co/blog/to-shade-or-not-to-shade
On Wed, Apr 20, 2016 at 10:36 AM Jong Wook Kim <jongw...@nyu.edu> wrote: > As per Guava version conflict, we should be able to shade the dependency > to another package, maybe with the whole asynchbase together. Guava > versions have been the PITA for many other projects too, and usually got > avoided this way. > > If we can avoid the Asynchbase+Guava issue by shading them and the only > interesting reason left to switch is the benchmark, it might not worth > going back to the blocking API as it will require a whole new threading > design. > > Sincerely, > Jong Wook > > > Sent from my iPhone > > > On Apr 19, 2016, at 9:01 PM, DO YUNG YOON <sho...@gmail.com> wrote: > > > > Hi All. > > > > Since implementing storage becomes easier(I believe), I think it is good > to > > have HBaseStroage which use HBase's native client. > > The reason I brought up this is following. > > > > 1. in some environment, especially specific Hadoop and Spark cluster > > distribution, > > s2core have guava version conflict which comes from asynchbase. > > - Many cases it is necessary to process stream of edges and write into > > HBase directly on streaming processing. > > - Currently, there is no way to specify version to avoid above problem. > > With Native HBaseClient, users will be select right version for there > > environment. > > 2. It would be fun to run benchmark on these two client. > > > > any feedback would be appreciated. > > > > Best Regards. > > DOYUNG YOON >
