Use ruby and utf-8 in editor mode strings.
Figure out homebrew hadoop+hbase.
Turn jbundler on in setup_load_paths.
Add warbler, so integration tests can get a jar into hbase.
Try making a region observer, figure out what we can mock.
Mark hbase and hadoop as maven "provided" scope.
Jarfiles, it turns out, are not actually ruby.

At least, not in the eyes of jbung^Hdler.
Back off to jruby 1.6.5 to match hbase.

If we're willing to accept ruby 1.8.7, this is by far the easiest way to get jruby into a coprocessor.

Walk away from nailgun and simple_cov; we may be able to get these back later.
Ditch jbundler, good heavens it is awful.

Just use maven instead to get jar deps.  Rig pom to just break out classpaths by scope into files in .jars.
Silence warble by inlining gemspec bundler directive.

Jeez.
Rename .jars/SCOPE.rb ->.jars/SCOPE_classpath.rb
Warbler!

Warbler has some annoying habits, so we hack its brain.  I'll probably care later, but I don't right now.

Specifically, it seems the gemspec trait will inline my project tree into any produced archives, no matter what.  Open the class and disable it.  It appears warbler wants all jars which do not use the gemspec trait to use the "no gemspec" trait, so similarly enable it.

Finally, the no gemspec trait apparently has no means for naming the default binary for jar execution.  When it is not named after the jar itself (say, because the jar bears a version) this produces an annoying warning.  Punch the binary name in as well.

Also fix some chicken-egg problems re: maven dependency resolution.
Compile a ruby region observer and include it in the jar.

Jar dependes on jrubyc.  Spec depends on jar (for coming integration tests.)

The included region observer (well, coprocessor) is stolen from the spike.
Type-A.
Put hbase version numbers in coprocessor type names.

This plays more nicely with the fact that jrubyc needs everything in the root namespace.
Ditch explicit hbase versions in identifiers.

This suggests we could maintain support for many hbase versions within a single build.  This isn't very realistic when you think about automated integration testing.

Instead, we'll make careful note about which version(s) of hbase are supported by which version of the library.
Bake the hbase version number into the jar filename.

Also note the pom's (unparameterizable) version is not normative.

We have a separate library version, and our "master" version is the concatination of the two.
Test the region observer's generated java type, not the ruby.

This requires us to give up our fancier mocking (constant replacement), but for it we gain the ability to test that it really implements the interface we think it does.

These shenanigans only apply to compiled ruby types.  I expect the vast majority of the library will be "plain", more easily-testable ruby code.
Try switching to a RegionObserver.

This breaks, but I'm pushing to toss it over to my emacs macro man.
Update README.md with full instructions.