We still have to use a Hadoop-compatible version of Guava on the server-side though, right? I believe the DFSClient has Guava dependencies.
> > On September 18, 2017 at 2:12 PM Mike Miller <mmil...@apache.org> wrote: > > Recently tickets have been opened dealing with Guava in Accumulo (see > ACCUMULO-4701 through 4704), in particular the use of Beta classes and > methods. Use of Guava comes with a few warnings... > > From the Guava README: > > *1. APIs marked with the @Beta annotation at the class or method level are > subject to change. They can be modified in any way, or even removed, at > any > time. If your code is a library itself (i.e. it is used on the CLASSPATH > of > users outside your own control), you should not use beta APIs, unless you > repackage them (e.g. using ProGuard).2.Deprecated non-beta APIs will be > removed two years after the release in which they are first deprecated. > You > must fix your references before this time. If you don't, any manner of > breakage could result (you are not guaranteed a compilation error).* > > I think it is worth a discussion on how to handle Guava dependencies going > forward across the different versions of Accumulo. The goal would be to > allow use of a newer version version of Guava in client applications with > the current supported versions of Accumulo. > > Ideally, we could just eliminate any use of Beta Guava code. But there are > Beta classes that are very useful and some which we already have > integrated > into released Accumulo versions. > > There seem to be 3 ways to handle Guava dependencies: > 1 - jar shading > 2 - copy Guava code into Accumulo > 3 - replace Guava code with standard Java > > We may have to handle it differently with each version of Accumulo. For > example, 1.8 has more widespread use of Beta annotated code than 1.7. >
