commit dfe23d9d6c5d9e17be95628b6ad12f5a490f0249
author Michael Bolin <mbolin@fb.com> Sun Nov 03 15:39:33 2013 -0800
committer Michael Bolin <mbolin@fb.com> Mon Nov 04 11:18:09 2013 -0800
tree e3f84a36be8e29d57ebc9a4d2dcfc6ade1ec97d2
parent 843f71792cb5820ca9fc98e0054ce018d5752be9

Fix a cache corruption bug caused by including a rule's output on its classpath.

Summary:
Apparently, a `java_library` was including its output JAR on the classpath when
building itself. This means that removing `srcs` from a `java_library` and then rebuilding
the rule would still succeed if the output JAR was still around from the previous build.
This would explain some rebuild issues that we have received anecdotal reports of,
but have not been able to reproduce.

This diff solves the bug by fixing `DefaultJavaLibraryRule.getDeclaredClasspathEntries()`
so that its return value matches that which is required by its Javadoc:

```
/**
 * @return The set of entries to pass to {@code javac}'s {@code -classpath} flag in order to
 *     compile the {@code srcs} associated with this rule.  This set only contains the classpath
 *     entries for those rules that are declared as direct dependencies of this rule.
 */
public ImmutableSetMultimap<JavaLibraryRule, String> getDeclaredClasspathEntries();
```

Test Plan:
Added an integration test to make sure changing the set of files in a java_library's srcs
causes a rebuild.
Added a unit test to make sure the `-classpath` argument passed to `javac` does not include
the output JAR of the `java_library` rule being built.