Gradle produces incorrect output when a file is removed from a source folder

Bugs
1

This is a tragic correctness bug that impacts at least 2.7 and 2.8. To reproduce:

mkdir repro && cd repro
echo "apply plugin: 'java'" > build.gradle
mkdir -p src/main/java
echo "public class T {}" > src/main/java/T.java
gradle jar
unzip -l build/repro.jar
# NOTE: T.class is present in jar
rm src/main/java/T.java
gradle jar
# NOTE: gradle claims jar is "up to date"
unzip -l build/repro.jar
# NOTE: T.class is still present.  Cry deeply.

A clean fixes the issue, but the lack of correctness here is extremely confusing to the user when encountered. Moreover, once a bad artifact is produced, it could easily poison the caches of other tools or build environments that use gradle with the expectation of a properly reproducible build (as happened to me).

Given the severity of this issue, the ease with which it is reproduced, and the sheer volume of potentially impacted users, I think this is an extremely high-severity bug.

2

I have determined that if T.java is not the only java file in the source folder / resource, then gradle correctly creates a new artifact with the old class file missing. That doesn’t alter the severity of this issue, only the likelihood of others to run into it, IMO.

3

(also confirmed present on gradle 2.9)

4

This is a known issue, GRADLE-2579. There are a few workarounds (not great admittedly) mentioned in the issue comments. This is an issue that we are considering prioritizing in a future gradle release.

5

Thanks for the pointer. I did honestly search for an existing bug, google fail on my part =)