They should be regular tasks (not sure what you mean by build tasks), and only the tasks that directly operate on their results should depend on them. Please see other forum topics on how to handle generated code.
By build tasks, I mean in the acyclic dag of dependencies, the first lifecycle task you hit (going in reverse dependsOn) is build:
generateCode <- buildProject <- build
versus
generateCode <- generate <- buildProject <- build
I guess the alternative (above) is a lot more awkward. It just seems conceptually easier to distinguish the kinds of tasks that generate code from the kinds of tasks that operate on that source code to generate projects. It seems like without separating those two tasks, things could get overly complicated.
I understand how to compile generated source code. I’m just asking echoing some of the thoughts on generalizing the process from a different perspective. You’re saying we should always explicitly specify all dependencies and use the lifecycle tasks only to group tasks into convenient categories.
edit: kind of fixed formatting.
FYI, “build” and “check” are in the java base, but not the base plugin. It would seem reasonable to move them up into base, otherwise non-java plugins define their own version of the lifecycle tasks, making them less standardized.