Does this mean we'd have guava in hadoop-client-modules and in hadoop-shaded-thirdparty? What you thinking Tsuyoshi Ozawa? Thanks.
Yes, it does. I choosed the way as a workaround because I think hadoop-client-modules shouldn't expose unshaded Guava to end-users of hadoop. Ideally, I would like to enclose shade inside hadoop-shaded-thirdparty completely to avoid its complexity.
I think using Curator itself is a good choice for stable ZKRMStateStore. There are lots things to use ZK correctly as you know, including connection handling, error handling, etc. Curator does these works instead of us.
> Could we get Curator to add a new set of APIs that use Curator-shaded Guava objects in their API instead? This would let us fully shade our Guava; the partial shading is unsatisfying.
Couldn't we do this shading ourselves? Or worst case, shade our curator use as well?
I think we can. For now, I created branch on my github as a trial.
Its diff from original version is small.
The problem is where to manage the code of forked version and where to push jar file. Under hadoop project?