Make gradle plugin configuration cache friendly

[trask]

The important change in this PR is removing the call to getProject(), see https://docs.gradle.org/current/userguide/configuration_cache_requirements.html#config_cache:requirements:use_project_during_execution

[raphw]

Good catch, thanks.

[raphw]

I just went through the project, and I wonder if this is a fix, or changing behavior.

Instead of getProject().fileTree(getTarget()).getFiles()), we now only have getFiles(). I am pretty sure that there is a reason for this call.

I also found that getProject() is still called in AbstractByteBuddyTaskConfiguration, and in AbstractByteBuddyTask. Are those uses also problematic, or does this not count as those are used to setup the task, and not to execute it?

@trask

[trask]

I just went through the project, and I wonder if this is a fix, or changing behavior.

Instead of getProject().fileTree(getTarget()).getFiles()), we now only have getFiles(). I am pretty sure that there is a reason for this call.

I think it's the same behavior

The old code:

• Called getProject().fileTree(getTarget()) which creates a ConfigurableFileTree representing all files under the target directory
• Called .getFiles() to enumerate them into a Set<File>
• Passed that set to deleteRecursively(Iterable<File> files), which iterates the collection and calls deleteRecursively(File file) for each file

The new code:

• Calls deleteRecursively(File file) directly on the target directory, which handles the recursion internally (checking file.listFiles() if it's a directory)

FWIW, we haven't seen any issue since implementing similar local patch: open-telemetry/opentelemetry-java-instrumentation#15313

I also found that getProject() is still called in AbstractByteBuddyTaskConfiguration, and in AbstractByteBuddyTask. Are those uses also problematic, or does this not count as those are used to setup the task, and not to execute it?

these haven't shown up as problematic for us, though we haven't finished updating the entire build to be configuration cache friendly yet: https://github.com/open-telemetry/opentelemetry-java-instrumentation/pulls?q=is%3Apr+Gradle+cache+in%3Atitle+is%3Aclosed+merged%3A%3E2025-11-11

[raphw]

It seems like the file tree resolution was indeed not meaningful. Still confusing to me how the other uses are ok, though, but it is neither obvious how they could be avoided. I will just keep this and wait for feedback if something needs to be adjusted.