Clearly the name is not being recommended, but hopefully it helps set the context for the idea.
Right now there are basically 3 ways for a user to cause tasks to get executed.
- Invoke a single task from the command line 2. Invoke no tasks from the command line (which causes defaultTasks to be utilized) 3. Invoke multiple tasks from the command line
Let’s ignore the case of the single task specified (either explicitly or by defaultTasks), as the ordering of tasks will be handled strictly by dependsOn() and mustRunAfter() relationships.
For the case of multiple tasks specified, they are still constrained by dependsOn() and mustRunAfter() relationships, but Gradle “enters” the task graph for each explicitly named task in the order they are specified on the command line or in the defaultTasks list.
dependsOn() and mustRunAfter() are relationships between tasks.
Invoking multiple tasks explicitly from the command line or using just defaultTasks does not affect the relationships between any tasks, but it does provide a means of passing an ordered list of task names to use to start traversal of the task execution graph.
What is currently missing is the ability to provide a “named” list of tasks to sequentially enter the task graph at. defaultTasks is essentially the “unnamed” list of tasks to sequentially enter the task graph at.
namedTaskList myNotify, ['build', 'notifyBuilt', 'analyze', 'notifyAnalyzed'] namedTaskLists(['ftpTransmit': ['bundle', 'ftp'], 'sshTransmit': ['bundle', 'encrypt', 'ssh']])
These would not create actual tasks, but just a way to reference a list of tasks for convenience at the command line, or via an IDE tooling invocation.
So running gradle tasks would result in something similar to the below.
Default tasks: a, b, c myNotify tasks: build, notifyBuilt, analyze, notifyAnalyzed ftpTransmit tasks: bundle, ftp sshTransmit tasks: bundle, encrypt, ssh
One question would be whether namedTaskLists with the same name as regular tasks for a project would take precedence (hide them essentially) or if it would be an error to have a namedTaskList with the same name as a task. Also, maybe these aliases are multi-project wide and you cannot have different “bindings” for different subprojects (or the last set one with the same name overwrites any previous list).