I have a task defined with

@OutputDirectory

. This task performs XJC generation of JAXB binding classes (the java files) into said directory. Between branches we changed the package in which these classes are generated. What we've noticed is that when switching branches the output from the "other" branch is not removed and we end up with compile errors. Annoying but understandable. However, what I don't understand is that even

clean

does not help the situation. The only thing that works is

clean

+

--no-build-cache

. Any thoughts on why that is? Would switching to

@OutputFiles

help with that in any way? The difference (to me anyway) is not immediately obvious from their Javadocs

The thing is, that Gradle doesn't know that package is "an input", that can change. So it thinks that no input has change and thus it gets old classes from build cache. I recommend you add package as a task input.

It does

Note that the best way to run "without cache" is with

--rerun

(reruns just one task) or with

--rerun-tasks

(reruns all in the chain). So just

gradlew compile --rerun (or  probably --rerun-tasks if problematic task is not compile task)

@InputFile
    @PathSensitive( PathSensitivity.RELATIVE )
    RegularFileProperty getXjcBindingFile() {
        return xjcBindingFile
    }

and

@OutputDirectory
    @PathSensitive( PathSensitivity.RELATIVE )
    DirectoryProperty getOutputDirectory() {
        return outputDirectory
    }

Yeah, it's important just for inputs

So can you confirm that

@InputFile

should see that the content of said file has changed?

Yes, when using

@InputFile

it will snapshot the file and if content changes the task will be out-of-date

I can understand why the old sources are still there. That's a function of not being able to make this an incremental task

is to add a property to always delete the contents of that directory as the first step in the task action

If your task is not incremental, then you always want to compile all sources again, so that makes sense

If no imputs changed, the action is never executed... so I probably don't even need a property - just do it

Np, and if performance is a problem, then creating an incremental task is an option to explore. But it's more complicated of course, and you have to handle cases like package change where you need to recompile all files again.

Right. The "problem" is that I really want this incremental relative to the OUTPUT, not the input

Oh, I see. Yeah, I guess this is harder then. You would need to read XSD and understand how XSD maps to Java file. And if XSD changes figure out what Java files you need to delete.

Yes, really someone woudl really finally need to spend time detangling that Ant task to proper design

my preference for tasks that generate code is to generate the files into a temporary dir, and then use

FileSystemOperations#sync

to transfer the generated files from the temp dir into the actual output directory. Using sync is best, because it means you won't end up with outdated files.