I would like to get two "lifecycle" tasks, or a new group of "tasks provided by Gradle": • `compile`: I just want to compile ALL code without running any test or any check. In my case it would be

tasks.register("compile") { dependsOn(tasks.withType<KotlinCompile>() }

, but KGP, Java, and any plugin that compiles could depends on it. • `generate`: I don't want to run ksp, proto, sqldelight, or whatever random task to generate everything in the project without compile (so, I don't want to run

assemble

). In some side projects I am doing

tasks.register("generate") { dependsOn(tasks.named { it.contains("generate") && it != "generate" } }

. But it would be great if plugins can just use a official one so I don't have to workaround any generation task that does not contain

generate

.

`compile`: that is called

assemble

assemble does not compile test AFAIK

for 1, maybe you could do something like

tasks.withType<Test>().configureEach {
    onlyIf { !project.hasProperty("skip.tests") }
}

./gradlew test -Pskip.tests

compile

would currently more be

classes

and

testClasses

(and any further

<sourceSet>Classes

)

assemble

would not include test but would do other stuff like building jar and so on.

generate

I would actually second, then IDEs would have a way to get all sources to disk. I usually create such a task myself and use

idea-ext

to configure IJ to call the task after sync, but would be nice if it just worked.

Another option for Kotlin projects is https://x.com/sellmair/status/1619308362881187840?s=46

That's a very implementation detail on which I would never rely. Or is it documented and guaranteed that this is always the case? I would always prefer

idea-ext

configuring an after-sync task, because that is documented and officially supported behavior

He is a JetBrains engineer and KGP and other Jetabrains plugins use that approach

So? It is an "insider tip" by a developer of that part. That is not an official documentation and support declaration, that task could tomorrow stop being called or even created. It just emphasize that this is an implementation detail you can (but imho never should) depend on. Especially not from a plugin. If JetBrains own stuff uses their undocumented implementation detail, that is for me no reason to use it too, especially if there is an officially supported and documented alternative instead. :-) But like always, just my opinion, do in your projects whatever you prefer and live with the consequences either way. :-)