We just released 1.3.5 yesterday, we have not yet put jars in a public maven repo. We are still working on that. I can make the patch use 1.3.5. Then the patch would build out of the box once we get the jars in a public repo.
We plan to start working on releasing 1.4 now. The patch leverages some newer features. Depending on when we release 1.4 and when the next Gora release, I would probably like to base it against 1.4 if possible. We have just started working on 1.5, so that release will not be soon. Upon entering incubation, 1.3 was our stable branch and we were just about to release 1.4.
The code should be pretty similar to the HBase data store. One place were I differed is that I made it possible for the user to choose different ways of encoding the data in Accumulo. The BinaryEncode is similar to what HBase does. The SignedBinaryEncoder encodes the data such that negative numbers sort first lexographically. This is useful if the Gora key is long and you want a query from -5 to 5 to work. If you want to use long as the key, but do not want to treat it as an unsigned long then you would not want to use this encoding. The HexEncoder uses ascii hex to encode long, int, float, double, I like this for debugging.
The mapping file is similar to hbase except for table setup. The table part of a mapping supports setting per table config key value pairs. This is how all tables are configured in Accumulo. Using this mechanism cache, localitly groups, bloom filters, iterators, compression, etc can all be configured for a table by setting key value pairs. The class part of the mapping is the same, except I added the encoder config.
Is this the type of high level info you were looking for?