This message was deleted.

Currently I'm seeing the warning

Execution optimizations have been disabled for task ':plugin:sourcesJar' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '/Users/cwalker/gradle-plugins/build/generated/sources/buildInfo/resources'. Reason: Task ':plugin:sourcesJar' uses this output of task ':plugin:generateBuildInfo' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to <https://docs.gradle.org/7.5.1/userguide/validation_problems.html#implicit_dependency> for more details about this problem.
Gradle detected a problem with the following location: '/Users/cwalker/gradle-plugins/build/generated/sources/buildInfo/resources'. Reason: Task ':plugin:sourcesJar' uses this output of task ':plugin:generateBuildInfo' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to <https://docs.gradle.org/7.5.1/userguide/validation_problems.html#implicit_dependency> for more details about this problem. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. Execution optimizations are disabled to ensure correctness. See <https://docs.gradle.org/7.5.1/userguide/more_about_tasks.html#sec:up_to_date_checks> for more details.

i have a similar issue and was planning on adding the dependency to processResources like you did. but apparently that doesnt work?

Wondering if it's just a bug wrt gradle 7.5? Or if this is an actual issue

The issue is that you are doing it wrong. Yes, you would need to add the dependency to each task that uses this output. But only as long as you keep that code smell. Practically every time you manually write

dependsOn

(except if on the left-hand side is a lifecycle task) you are adding a code smell you should not do. Always prefer proper implicit task dependencies over configuring hard-coded paths and adding manual

dependsOn

statements in a try to fix the problems that might become obvious or not so much. What you instead want is

sourceSets.main {
    resources.srcDirs(generateBuildInfo)
}

then all outputs of the task are automatically treated as resources and all tasks that need it get the task dependency automatically. If you only need one of the output properties of the task, then use that, as long as it is declared as proper output and is a property or file collection, it should still carry over the task dependency. If all that does not work because you for example just need one file from many generated as output by the task, you can either add an intermediary task that has exactly what you need as output and the generation task as input, or you specify that file explicitly but specify with

builtBy

which task generates that file so that again the dependencies can be added automatically.

@Vampire brilliant! I couldn't use

@OutputFile

because it complains that the

Source directory .../resources/build-info.properties

is not a directory.

it would be better to use

project.layout.buildDirectory.dir("generated/sources/buildInfo/resources")

instead of

buildDir

Thanks @ephemient! I'll try to remember

project.layout

going forward.

I used something like

tasks.named<ProcessResouces>("processResouces") { from(generateBuildInfo) }

(or

into("some-dir") { from(generateTaskInfo) }

) in such cases to add implicit dependency on the generated resources. Not sure if this way is the best way but it worked for me. I'll try adding to the source set as @Vampire adviced next time to compare, it certainly looks more concise

Well, it is a semantical difference too and I followed the original semantics. The question is whether you want all consumers of the

processResources

task to have the file, or all consumers of the source resources.

Yeah but in my cases it doesn't matter. Usually consumers just use resources secondary variant

It's less about outside consumers, than more inside consumers, like a task that does something with resources like packing them together in an archive for example.

No need for packing in this case, but tasks that run tests should see the resource.

That should be true with both solutions