I quickly modified the POM files and moved the generated code around to put the thrift stuff in a separate module to see how easy this would be. There are some issues:
1. I don't have commit access yet, so I can't "svn mv" to keep svn history during refactoring (so I'll need to work with a committer to reproduce those in a sequence of commits, or else we lose that info in the patch I would otherwise provide).
2. I don't have a sense of what the abstraction would look like, except possibly just looking at the thrift definitions and creating Java interfaces that match. Without that, I can simply move the thrift stuff aside and update the dependencies in the build (which would still be useful on its own), so we'll need some work on creating the interfaces for the abstraction.
3. We need a name for the sub-modules. I was originally going to call it "accumulo-api", with "accumulo-api-thrift" as the artifactId for the abstraction and thrift implementation, respectively. However, "api" is misleading, because somebody might think this contains the public API, which is actually in the "accumulo-core" artifact (should probably be in a "accumulo-client" one, but that's a separate concern). "accumulo-rpc" was suggested (with "accumulo-rpc-thrift" being an implementation).
4. This is not useful to consider yet, because there is only one implementation, but at some point, some consideration is going to need to be made to decide how to swap out implementations. This could be done with an annotation scanning framework with drop-in jars, a configuration change with classes being available on the classpath, or a build-time configuration. This is a future consideration, though. Not relevant for this ticket... just documenting to put it on record.