Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

[ Updated 16 April 2021, see reproducible test case below.]

I started converting a small Gradle build to Gradle 7.0. It says:

> Task :junit_xsd
Execution optimizations have been disabled for task ':junit_xsd' to ensure correctness due to the following reasons:
  - Gradle detected a problem with the following location: '/Users/ndw/Projects/xproc/test-suite/build'. Reason: Task ':git_log_shorter' uses this output of task ':junit_xsd' 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.0/userguide/validation_problems.html#implicit_dependency for more details about this problem.
I've looked at the documentation link and it wasn't very informative (to me).
The two tasks in question are, AFAICT, unrelated. junit_xsd is a simple copy task:
task junit_xsd(type: Copy) {
  from "src/main/schema/"
  into "build/"
  include "*.xsd"
The git_log_shorter task is a bit harder to describe. It's a custom task that runs a process I wrote.
task git_log_shorter(dependsOn: ["git_log_summary"], type: XMLCalabashTask) {
  inputs.file "tools/xsl/shorter-log.xsl"
  inputs.file "build/git-log-summary.xml"
  outputs.file "build/git-log-shorter.xml"
  input("source", "build/git-log-summary.xml")
  output("result", "build/git-log-shorter.xml")
  pipeline "tools/xpl/run-xslt.xpl"
  option("stylesheet", "../xsl/shorter-log.xsl")
But it doesn't read any xsd files, so I can't work out why Gradle thinks there's an implicit dependency on junit_xsd.
I mean, I suppose it reads out of the build directory, but I have lots of tasks that create and use temporary files from the build directory. I'll be a little shocked if any task that reads from the build directory is now implicitly dependent on every task that writes to it.
If that is the case, what's the proposed solution for temporary files?
The git_log_summary task, for example, is the task that writes build/git-log-summary.xml and I have an explicit dependency for that task.
Am I overlooking something obvious?
Here's a test case that doesn't involve any extension steps. Running the doall task produces the warning:
task doall(dependsOn: ["copyA", "pointless_gzip"]) {
  // nop
task copyA(type: Copy) {
  from "src/main/data/"
  into "${buildDir}"
  include "*.xsd"
task pointless_tar(type: Exec) {
  outputs.file "${buildDir}/pointless.tar"
  commandLine 'tar', '-cf', "${buildDir}/pointless.tar", 'src'
  doFirst {
    mkdir("${buildDir}")
task pointless_gzip(dependsOn: ["pointless_tar"], type: Exec) {
  inputs.file "${buildDir}/pointless.tar"
  outputs.file "${buildDir}/pointless.tar.gz"
  commandLine 'gzip', '-k', "${buildDir}/pointless.tar"
                I got a nice explanation of this situation over on the Gradle forums, discuss.gradle.org/t/…
– Norm
                Apr 16, 2021 at 12:23
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.