Remove usage of internal gradle classes in task dependencies

[atyrin]

Intermediate fix #2822

Switch in using storage of child tasks from an internal set of paths to Gradle set dependsOn.

Changes:

• add check for a type inside addChildTask(path: String)
  • it will produce a warning in the import process if we can resolve the task by the path and it is not an AbstractDokkaTask. That part is changed compared with 1.7.20 (previously reported only on executing of :dokkaHtmlMultiModule).
  • it will not report anything during the import if we cannot resolve the task by the path. Otherwise, we will report the errors during the import if some submodules don't have applied the Dokka plugin.
• fix formatting for an error message if there is no submodule with applied Dokka.

[atyrin]

Also, I noticed that addSubprojectChildTasks, removeSubprojectChildTasks, removeChildTasks(projects: Iterable<Project>, childTasksName: String), addChildTasks(projects: Iterable<Project>, childTasksName: String) don't work in runtime (in project build files) but works during configuration (during pairing subproject files and parent)
(in 1.7.20 the same)

tasks.dokkaHtmlMultiModule.configure {
    addChildTask(":kn-moodule:dokkasub") // works
    addChildTasks(setOf(project(":kn-moodule")), ":dokkasub") // doesn't work
}

[atyrin]

We have one more reference for internal package: import org.gradle.api.internal.plugins.DslObject inside /dokka/runners/gradle-plugin/src/main/kotlin/org/jetbrains/dokka/gradle/AbstractDokkaLeafTask.kt

[IgnatBeresnev]

Overall LGTM 👍

[vmishenev]

Can you rebase onto master?

[atyrin]

In the current approach, there is an issue for the scenario when there is a task that depends on AbstractDokkaParentTask, e.g.:

tasks.create("X"){
    dependsOn(tasks.getByName("dokkaHtmlMultiModule"))
}

In such configuration, Gradle throws an exception for calls like this project.tasks.findByPath(path).

Caused by: org.gradle.api.internal.AbstractMutationGuard$IllegalMutationException: Gradle#projectsEvaluated(Action) on build 'dokka-sandbox' cannot be executed in the current context.
	at org.gradle.api.internal.AbstractMutationGuard.createIllegalStateException(AbstractMutationGuard.java:39)
	at org.gradle.api.internal.AbstractMutationGuard.assertMutationAllowed(AbstractMutationGuard.java:34)
	at org.gradle.invocation.DefaultGradle.assertProjectMutatingMethodAllowed(DefaultGradle.java:287)
	at org.gradle.invocation.DefaultGradle.projectsEvaluated(DefaultGradle.java:354)
	at org.jetbrains.kotlin.gradle.plugin.DefaultKotlinBasePlugin.apply(KotlinPluginWrapper.kt:79)
	at org.jetbrains.kotlin.gradle.plugin.KotlinBasePluginWrapper.apply(KotlinPluginWrapper.kt:184)
	at org.jetbrains.kotlin.gradle.plugin.AbstractKotlinMultiplatformPluginWrapper.apply(KotlinPluginWrapper.kt:311)
	at org.jetbrains.kotlin.gradle.plugin.KotlinMultiplatformPluginWrapper.apply(PluginWrappers.kt:74)
	at org.jetbrains.kotlin.gradle.plugin.KotlinMultiplatformPluginWrapper.apply

So, the idea to put in dependsOn only resolved tasks is not working.

[IgnatBeresnev]

Well, at least now we know! @atyrin thanks for the research

Proposing to do the following:

1. Since we're working on project isolation and we're aiming to include it in the stable release, I don't think spending any more time trying to make the dependsOn change work makes sense. We tried it as an easy drop-in solution, but it turned out to be more difficult than I imagined. Hopefully, the internal Gradle API will not change dramatically until the stable release. So proposing to revert the dependsOn part.
2. We're going to remove public API methods such as addChildTasks and removeChildTasks anyway, so I'm proposing to keep the deprecation
3. This research was very valuable, maybe it was the whole reason why it was implemented through the internal API and not via dependsOn, so it makes sense to leave a short comment with a link to this PR

[atyrin]

I've created a separate PR for further updates regarding deprecations only: #2857