tree e3f84a36be8e29d57ebc9a4d2dcfc6ade1ec97d2
parent 843f71792cb5820ca9fc98e0054ce018d5752be9
author Michael Bolin <mbolin@fb.com> 1383521973 -0800
committer Michael Bolin <mbolin@fb.com> 1383592689 -0800

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.