These annotations are actually helpful... although there may be another way of accomplishing the same goal.

If they are helpful, that's different, but may I ask how are they helpful? My understanding is that this annotation will relax the visibility of private methods during testing. All of our uses of it, though, are as decorators on protected and public functions.

That annotation is purely informative. It's not within the power of any annotation to break visibility.

Yes, I find them helpful from an informational perspective. public and protected methods mean increased responsibility. It is useful to know that some methods have been relaxed from private for the sake of unit testing.
Instead of simply removing these annotations, I would suggest replacing them with a prominent comment/javadoc that communicates the same idea.

I'm not sure I even want to remove the annotation. What is the advantage of so doing and adding Javadocs? Is it the Guava dependency that bugs you, @acoburn ?

Okay, well, if it's blocking OSGi, that's a good reason to remove it in favor of docs. Why on Earth is MODE loading Cassandra drivers?

...and can we prevent such loading?

Modeshape allows you to optionally store binary files in Cassandra, so it lists this as a dependency. In principle, modeshape's MANIFEST.MF file should specify the dependency as optional, but we are not so lucky. That is, the dependency is unnecessary from the perspective of fcrepo-kernel-modeshape, but from the modeshape-jcr module, it is a hard dependency.

The confusing thing, though, is that the datastax module shows the guava import can be anything in the version range [14-19) https://github.com/datastax/java-driver/blob/2.0/driver-core/pom.xml#L192, but when I actually try to start that bundle in Karaf, it claims to require only version 16.

And no, I can't prevent the cassandra drivers from needing to be loaded. Nor have I had any luck with setting the resolution of that bundle to optional. The problem appears to be that it is a transitive dependency, and so it's rather out of our control unless we start doing things like creating a fat jar, shading, etc, etc (which I'd prefer to avoid).

OSGi trumps @VisibleForTesting.
...but please leave a comment or the like in the code to communicate the same idea.

I'm actually inclined to close this PR, leaving the @VisibleForTesting annotation in place. The issue I'm trying to resolve at present relates to version mismatches 18.0 != 16.0.1, but @VisibleForTesting is available in both versions, so even if we downgraded to guava 16.0.1, we could still use this annotation.