Hi Gradle team,
Will this extensibility model include "default" or "reserved" tasks? I've noticed the following warning in one of my builds while evaluating 2.4, so I'm curious if something similar is already in the works:
Defining custom 'build' task when using the standard Gradle lifecycle plugins has been deprecated and is scheduled to be removed in Gradle 3.0
Defining custom 'clean' task when using the standard Gradle lifecycle plugins has been deprecated and is scheduled to be removed in Gradle 3.0
Something I've noticed with more complex projects is that Gradle doesn't have a sense of high level workflow. Most plugins like to follow similar conventions and define tasks like build and clean, which makes it impossible to run two plugins that each define those methods side by side or for a root project to add extra steps to a build tasks if it doesn't already exist for a given project.
I think it would be a good idea to have key conventional tasks (e.g. clean, build, test) reserved, even if they are blank and not wired together, at the top level of a project and require plugins to extend the default tasks by adding their tasks as a dependency. So instead of the java plugin defining it's own build task, it would have a task buildJava that is added to the build workflow through a call to build.dependsOn "buildJava". Likewise if I have a python plugin that operates on the same project, it would add it's tasks to the default workflow with a call to build.dependsOn "buildPython". Now both my python and java plugins can exist side by side, and furthermore I can add dependencies between the plugins and say something like buildPython.dependsOn "buildJava".