Hi, Is it possible to find out which files in the output of a sourceSet are stale, so they can be ignored or deleted? After switching branches and compiling, the class files from the old branch are still there, even if the source is not, and they are added to the jar, if forbidden-apis does not choke on the file. Incremental compile does not seem to make a difference, forcing

classes

to run does not cause it to remove the stale class in either case.

This sounds like a problem of the

classes

tasks? If incremental, it should delete the stale files. If not, it should delete the destination content before writing the new one

That would be easiest, yes. Do you mean this should already be the case that

classes

does this (which might point to some error in my build), or is that more of a wish that it should do that?

I would naively expect this indeed.

It is java. I'll try to get a minimal reproducer, to rule out my own setup

name: :classes
type: class org.gradle.api.DefaultTask
inputProperties:
 - 
inputsFiles:
 - 
sourcefiles:
 - 
outputs:
 - 
dependencies:
 - :compileJava
 - :processResources

So

classes

looks like it's a lifecycle task

I deleted a needed class file, so it should not make a difference which task it really is. Thanks for checking the behaviour, though, I'll try to find where I'm going wrong

IIRC, Gradle's behavior might change when an output directory is "shared" by multiple tasks (i.e. two tasks configured with the same output directory).

Thanks for the hint, I don't think I would have looked for that first, but that sounds quite likely now that you mention it

two tasks configured with the same output directory

Are there valid use cases for this? Sounds like Gradle should give an error for this?

With

-i

, I don't see any message about overlapping outputs, only that removing a different class file indeed caused a full rebuild:

Task ':foo:compileJava' is not up-to-date because:
  Output property 'destinationDirectory' file foo\build\classes\java\main\foo\Bar.class has been removed.
The input changes require a full rebuild for incremental task ':foo:compileJava'.

That did not remove the offending class file, though.

Could it be a bug from case insensitive filesystem?

Very much so. The stale file had it's own package. Let me give that a try in my reproducer, maybe gradle leaves directories alone, as opposed to files in an existing output package dir.

that removing a different class file indeed caused a full rebuild:

Yes an incremental task can only be incremental when incremental inputs change. As soon as another input or the output changed, a full rebuild is necessary.

That did not remove the offending class file, though.

But the full rebuild usually should also clean up the outputs. One thing that produces similar situations is if you have build cache enabled and there is a poisoned cache entry or inputs and outputs not declared properly for a task.

So, I think I've finally been able to track down the reason for this problem and it's quite the corner case. Thank you all for helping me figure this out by ruling out the more likely suspects! Our build is structured with a small number of included builds configured via

settings.gradle

, because they are an integral part of the build. For simplification, we recently re-integrated one of those into the main build again, without changing the directory structure. So what was previously a subproject in an included build is now a subproject in the main build. The offending file resided in exactly one of those subprojects. First building the old branch with the included build and then a newer branch in the same workspace exhibits the problem. Gradle then considers

previous-compilation-data.bin

invalid, which it would normally use to find out which .class files are needed, and it does not delete anything.

Sounds like a bug you should report I guess. With it being quite a corner case maybe it could need some time, but it should probably not be kept around either way.

Good point, here it is: https://github.com/gradle/gradle/issues/33933