In a Gradle project with a number of tasks, how can I query the up-to-date state of a task after project evaluation?
Or, putting it another way, how can I check if the task will be executed without actually running the build?
Hi Nikita,
currently, you cannot query the up-to-date state of a task without trying to execute it. Could you provide your use-case, so we can either provide a different solution to your problem or add the desired feature to Gradle?
Cheers,
Stefan
The use case is a small IDE feature (“show bytecode for a class”). If the class is built by Gradle, the IDE needs to check, if the resulting class file is up-to-date.
Since checking up-to-dateness of a task without executing is not possible at the moment, what will happen in the IDE now? How will the IDE experience improve once such capability is provided?
at the moment, Byte Code Viewer does not work, when building is delegated to Gradle. Once IDE can determine up-to-date state of a task, it will be able to handle the case of out-of-date sources by interacting with user (e.g., suggest to run the build or put off the operation).
What we can do is check the up-to-date state of the ancestry of a SourceSet
, i.e. check the up-to-date state of the tasks building the source set and all of their dependency tasks. This is possible to implement currently.
You can’t query the state of a task by itself, as dependent tasks might modify its state. However, if all the task’s dependencies are up-to-date, then we can determine whether or not the task is up-to-date just by looking at its inputs and outputs.
@n_s_skvortsov Wouldn’t simply running the task work for you? If it’s up-to-date, Gradle will not make any changes.
In current IntelliJ workflow, the user is asked if compilation should be triggered ( as it is time/cpu consuming and may not be suitable to do a the moment ). Just running a task unconditionally does not seem to be a good plan. I think, I could add some “beforeTaskAction” listeners and stop Gradle right before anything is executed, assuming this means “out of date”.
@n_s_skvortsov: Have you been successful with using TaskListener.beforeActions
to implement your use case?