Hello! I'd like to use Dokka in an Android library...
# dokka
o
Hello! I'd like to use Dokka in an Android library project to generate completely independent HTML sites for each build variant, as these variants have differences in their exposed API. I know how to do that using Dokka V1. I can declare a new Task for each Android variant I'm interested in, make it a
DokkaTask
, and suppress the source sets I'm not interested in. How would I achieve this with V2, as registering Dokka tasks now seems to be unsupported?
This looks like it's working:
Copy code
dokka {
    moduleName = "Sample"
    pluginsConfiguration {
        html {
            footerMessage = "© Hello World"
        }
    }

    dokkaSourceSets.configureEach {
        suppress = true
        perPackageOption {
            matchingRegex.set(".*\\.internal(\\..*)?")
            suppress = true
        }
    }

    dokkaPublications.configureEach {
        suppressInheritedMembers = true
    }
}

android.libraryVariants.configureEach { variant ->
    tasks.register("dokkaGeneratePublicationHtml${variant.name.capitalize()}") {
        group = "dokka"

        dependsOn(tasks.named("dokkaGeneratePublicationHtml"))

        dokka {
            dokkaSourceSets.create("custom_${variant.name.capitalize()}") {
                displayName = variant.name
                suppress = false
                suppressGeneratedFiles = false

                sourceRoots.from(
                        dokkaSourceSets.getByName(variant.buildType.name).sourceRoots,
                        dokkaSourceSets.getByName(variant.flavorName).sourceRoots,
                        dokkaSourceSets.getByName(variant.name).sourceRoots,
                        dokkaSourceSets.getByName("main").sourceRoots,
                )
            }
        }
    }
}
o
Hey! Yeah, with the new Gradle plugin, it's not possible to register additional tasks. It's possible to configure custom
format
tasks, but the sourceSets configuration will be shared across all tasks/formats. Do you mind sharing the use case on why you need to
generate completely independent HTML sites for each build variant
? Is it like an internal multi-flavor library? It would help to better understand the requirements and possibilities Coming back to your example, I'm not sure that this will work correctly when building documentation for all variants simultaneously, as those source sets will be shared across all tasks. One option, if that's fine, could be to create a Gradle property, and select (or suppress) specific variants based on it, so that you will be able to do something like this:
Copy code
./gradlew :dokkaGenerate -PuseVariantForDokka=main
o
Hello, thank you for your reply! Our use case is that we're publishing a privately distributed library that consists of a single multi-flavor module, with one flavor per customer. Each flavor is set up with different source sets, and each flavor has its specific entry-point interface. When we build an AAR from this module for a specific customer, it only contains their entrypoint, which I want to reflect in our docs. However, with a default Dokka setup, all entrypoints will be visible as different Dokka sourcesets, and this is a no-go for business reasons. I'll consider using a Gradle property for filtering, thank you for suggesting it; we only ever publish one flavor at once so my setup would work as well, but it's messier for sure. I understand the new Dokka API makes this complex to achieve, but I don't think Android flavors are really that niche of a use case, I hope Dokka gets better support/documentation for them in the future.
o
Got it! Feel free to subscribe to https://github.com/Kotlin/dokka/issues/2078 While flavors are popular in Android, there was not a lot of interest in support for them in Dokka (or at least, we don't hear about it very often) There are no flavors/variants in KMP or just Kotlin/JVM, so it was not our priority, as it feels like Dokka is mostly used by public libraries Still, it might be supported in future, of course
o
Understood, thank you. I don't know anything better than Dokka for generating API reference, so I hope it can grow to cover all kinds of use cases in the future 🙂
👍 1