[GRADLE-3404] Consider args, working directory and executable/main as inputs for JavaExec/Exec Created: 20/Feb/16  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Sterling Greene Assignee: Unassigned
Resolution: Won't Fix Votes: 0


Since JavaExec and Exec tasks do not declare any outputs (with @OutputFile, @OutputDirectory, etc), tasks of this type will never be up-to-date.

If build author creates a JavaExec/Exec task and adds outputs themselves (outputs.file ...), some surprising behavior can occur.

Situation 1:
1. Exec task declares output
2. Build author mistakenly passes the wrong arguments to the executable (e.g., output goes to the "wrong" place or the script fails without a failing exit code).
3. Build is executed. Mistake is found.
4. Build author fixes Exec task's args.
5. Build is executed, but Exec task is up-to-date.

Situation 2:
1. Exec task declares output and inputs.
2. Build author does not set the working directory. The executable implicitly looks for files with a particular extension in the working directory.
3. Build is executed. Output is "missing" because no input files were found.
4. Build author fixes Exec task's working directory.
5. Build is executed, but Exec task is up-to-date.

Situation 3:
1. Exec task declares output.
2. Build author mistakenly uses the wrong executable due to copy and paste.
3. Build is executed. Output is "missing" because the executable accepts the same sort of arguments, but produces different output.
4. Build author changes Exec task's executable.
5. Build is executed, but Exec task is up-to-date.

JavaExec has a similar set of situations (or more if we consider system properties and JVM args too).

This is an annoyance when developing build scripts/plugins, but this can really cause a lack of trust with build users if a mistake like any of the above make it to them. They would need to re-run the build with --rerun-tasks or locally change the task in a way that Gradle will notice. This problem also cuts across our general advice to always declare inputs and outputs for a task.

The workaround is to use a custom task that wraps project.exec or extends JavaExec/Exec with the appropriate annotations. Or to manually add the command-line, executable and working directory as an input (inputs.property ...). A custom task is usually better in this case since build users won't have to worry about the exact command-line to pass to executables.

If we were to consider workingDir, executable and args as @Inputs, we could potentially cause existing builds to execute more often than they do today. I think in most cases, this would be the expected behavior and the task would have been considered broken before. There may be cases where the order of the arguments are not important (and possibly change between builds). For tasks like that, the build author could impose an ordering to keep the list of arguments stable.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:47:56 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.