Schedule artifact transforms early (#5657)Schedule artifact transforms early when possibleBefore this change artifact transforms were executed as late as possible, typically when snapshotting the task's input that would consume them. With this change artifact transforms are scheduled like tasks whenever possible, and are executed as soon as all their dependencies are built.The execution engine now understands three different kinds of "work":- tasks in the current build (this is the most typical type of work)- tasks from another included build referenced from the current build- artifact transforms discovered via task inputsThere are two kinds of artifact transforms that are not executed alongside tasks after this change:- transforms that never appear in a task's (or another transform's) inputs- transforms that transform file dependenciesThese cases are handled as before, i.e. the transforms are executed when they are consumed.Some types have been introduced to cover the new concepts of work and transforms wrt building the graph of work. Several existing types are still have "task" in their names even though they now work with more than just tasks. These should be renamed/refactored in follow-up PRs.
Re-use `TaskDependencyResolveContext` during task graph building (#3807)All dependency resolution in Gradle should happen via TaskDependencyResolveContext during when building the task graph. Calling `DefaultTaskDependency.getDependencies(task)` should be avoided since it creates a new `TaskDependencyResolveContext` and needs to calculate the dependencies again.`SkipTaskWithNoActionsExecuter` now re-uses the `TaskExecutionGraph` to determine the dependencies of a task instead of re-evaluating them. After this commit, the task properties are resolved at three places:- When building the task graph for walking the input files- When checking if there a task can be executed in parallel with the currently running tasks based on on the declared outputs, destroyables and task local state- For using the task properties during task executionThe last two places could still be unified into one, but that seems to be a little bit more complicated.
Extracted TaskDependencyContainer out of TaskDependencyInternal, to represents something that is a source of task dependencies. An object declared as a dependency may implement this, as an alternative to Buildable.