[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
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.
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:
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.