commit e39116c1026936ceed670bccc1a002d6eb23a83c
author Michael Bolin <mbolin@fb.com> Tue Jun 25 14:49:46 2013 -0700
committer Michael Bolin <mbolin@fb.com> Mon Jul 01 23:48:23 2013 -0700
tree 2a7a754e70a9e96cc5c7e201fca98652ca5766dc
parent 21a4223592f654a3cf25db1e4d3f7f655672e9e7

Re-introduce the ABI computation in JavacInMemoryStep.

Summary:
This turns out to be much more complicated than the original version
because this version relies on passing information through files whereas
the original version was able to pass the ABI key around in memory.

The code in the `com.facebook.buck.java.abi` package is now compiled
into a separate directory of `.class` files. This directory is specified via
`-Dbuck.abi_processor_classes` in `buck_common`, much like we do
for our testrunner.

`JavacInMemoryStep` now takes an optional path to a file where an ABI
hash should be written. If the path is specified, an
`AbiWritingAnnotationProcessingDataDecorator` is passed to
`JavacOptions.appendOptionsToList()`, which is used to include the
`AbiWriter` as an annotation processor.

In general, we expect most clients of `JavacInMemoryStep` to request
the ABI for the code being compiled, `UberRDotJavaUtil` being the
notable exception.

Finally, in an attempt to provide a layer of indirection around the
mangling of `AnnotationProcessingData` that occurs in order to inject
our annotation processor, this diff introduces the concept of
an `AnnotationProcessingDataDecorator` to "decorate" the user's
`AnnotationProcessingData` with our additional processor.

A `AnnotationProcessingDataDecorators` utility provides a default,
pass-through implementation of `AnnotationProcessingDataDecorator`.

Note that this diff does not add the logic where `DefaultJavaLibraryRule`
will read the ABI from the file written by `JavacInMemoryStep`,
as that will be done in a follow-up diff.

Test Plan: Sandcastle builds.