Modules with kapt plugin fails with implicit dependency error

[adjorno]

Describe the bug After ugrading Gradle to 8.2.1, Kotlin to 1.9.0 and Dokka to 1.8.20 the modules using kapt plugins started failing on :dokkaHtml gradle task execution with implicit dependency error.

Expected behaviour Dokka successfully finishes.

Screenshots

    Reason: Task ':kaptmodule:dokkaHtml' uses this output of task ':kaptmodule:kaptDebugKotlin' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

    Possible solutions:
      1. Declare task ':kaptmodule:kaptDebugKotlin' as an input of ':kaptmodule:dokkaHtml'.
      2. Declare an explicit dependency on 'kaptmodule:kaptDebugKotlin' from ':kaptmodule:dokkaHtml' using Task#dependsOn.
      3. Declare an explicit dependency on ':kaptmodule:kaptDebugKotlin' from ':kaptmodule:dokkaHtml' using Task#mustRunAfter.

    For more information, please refer to https://docs.gradle.org/8.2.1/userguide/validation_problems.html#implicit_dependency in the Gradle documentation.

To Reproduce run :dokkaHtml 2 times. It will fail on the 2nd run, probably something related to Gradle caching.

Dokka configuration Configuration of dokka used to reproduce the bug

tasks.dokkaHtml.configure {
    outputDirectory.set(file("../documentation/kaptmodule"))
    this.dokkaSourceSets.getByName("main") {
        skipDeprecated.set(true)
        includeNonPublic.set(false)
        skipEmptyPackages.set(true)
        reportUndocumented.set(false)
        perPackageOption {
            matchingRegex.set(".*\\.internal.*") // will match internal and all sub-packages of it
            suppress.set(true)
        }
    }
}

Installation

• Operating system: macOS 13.5
• Build tool: Gradle v8.2.1
• Dokka version: 1.8.20

[IgnatBeresnev]

Hi! This is interesting... I'm struggling to see why Dokka would depend on kapt, but perhaps this is a variation of #3153?

Could you please update to Dokka 1.9.0 and try the workarounds suggested in #3153?

[fobidlim]

Same errors on me, using Gradle 8.3, Kotlin 1.9.10, Dokka 1.9.0

build.gradle.kts

tasks.withType<DokkaTaskPartial>().configureEach {
            outputDirectory.set(layout.buildDirectory.get().dir("docs"))
            dokkaSourceSets {
                pluginsMapConfiguration.set(
                    mapOf(
                        "org.jetbrains.dokka.base.DokkaBase" to
                            """{ "separateInheritedMembers": true }"""
                    )
                )
            }
        }

It is same, whether belows added or not.

gradle.properties.kts

org.jetbrains.dokka.classpath.useNativeDistributionAccessor=true
org.jetbrains.dokka.classpath.useKonanDistribution=true
org.jetbrains.dokka.classpath.excludePlatformDependencyFiles=true

Reason: Task ':core:common:dokkaHtmlPartial' uses this output of task ':core:common:kaptDebugKotlin' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

    Possible solutions:
      1. Declare task ':core:common:kaptDebugKotlin' as an input of ':core:common:dokkaHtmlPartial'.
      2. Declare an explicit dependency on ':core:common:kaptDebugKotlin' from ':core:common:dokkaHtmlPartial' using Task#dependsOn.
      3. Declare an explicit dependency on ':core:common:kaptDebugKotlin' from ':core:common:dokkaHtmlPartial' using Task#mustRunAfter.

    For more information, please refer to https://docs.gradle.org/8.3/userguide/validation_problems.html#implicit_dependency in the Gradle documentation.

Reason: Task ':core:common:dokkaHtmlPartial' uses this output of task ':core:common:kaptReleaseKotlin' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.

    Possible solutions:
      1. Declare task ':core:common:kaptReleaseKotlin' as an input of ':core:common:dokkaHtmlPartial'.
      2. Declare an explicit dependency on ':core:common:kaptReleaseKotlin' from ':core:common:dokkaHtmlPartial' using Task#dependsOn.
      3. Declare an explicit dependency on ':core:common:kaptReleaseKotlin' from ':core:common:dokkaHtmlPartial' using Task#mustRunAfter.

    For more information, please refer to https://docs.gradle.org/8.3/userguide/validation_problems.html#implicit_dependency in the Gradle documentation.

[IgnatBeresnev]

@fobidlim thanks for trying it out!

Is the project where it is happening open source by any chance? Having a reproducer would simplify debugging by a lot

[fobidlim]

@IgnatBeresnev The project is not open source. In my case, migrate kapt to ksp, problem is solved.

[adjorno]

@IgnatBeresnev Our project is also not open-source. I solved the issue by adding the explicit dependency in all kapt modules:

afterEvaluate {
    tasks["dokkaHtml"].dependsOn(tasks.getByName("kaptReleaseKotlin"), tasks.getByName("kaptDebugKotlin"))
}

[milgner]

@adjorno much appreciated! I had to slightly adopt it for my case but it got rid of the message!

target.afterEvaluate {
    target.tasks.named("dokkaHtmlPartial").configure {
        dependsOn(target.tasks.getByName("kaptKotlin"))
    }
}

[valya1]

We have the same issue with using dokka + kapt in our project, will it be fixed in future dokka release?

[lmachacek]

@adjorno & @milgner Thanks guys for the inspiration! In our case this helped:

    afterEvaluate {
        tasks.named("dokkaJavadoc").configure {
            dependsOn(tasks.getByName("kaptKotlin"))
        }
    }

We are using Gradle 8.5, Dokka 1.9.10 and Kotlin 1.9.21.

[winniegr]

I use the same, but have the error: cannot find task kaptKotlin/kaptReleaseKotlin, can anyone help me?

[kingargyle]

This seems to be related to when a build is running multiple modules in parallel. If you run the dokka tasks individually in each module they will work fine. However as soon as you try to run multiple it starts to fail as if some singleton instance is being set that then affects everything else.

Can't provide a sample code as it is happening on work builds. In some cases doing the depends on works but in a large mulitmodule build it just shifts the issue to another module that was working before.