https://kotlinlang.org logo
Join Slack
Powered by
Dokka 1.9.20 has been released! :kodee-happy: Thi...
# dokka
i
Dokka 1.9.20 has been released! kodee happy This release consists mostly of bugfixes (release notes here), and it should be safe to update to Behind the curtain, we are working hard on a couple of major issues that significantly improve user experience and stability, so the most exciting and noticeable updates are yet to come, stay tuned 🙂
🎉 5
🚀 1
s
Out of curiosity, is a merge with dokkatoo still planned for some point?
o
Yeah! Dokkatoo will be a foundation of the new Gradle plugin, setup/DSL will be a little different though So, stay tuned, this is a part of ‘most exciting and noticeable updates’ 🙃
👍🏻 1
🎉 2
k
I was hoping to see Dockatoo in this release so I don't have to try integrating w/ that temporarily 🙂 Any rough idea on when the new gradle plugin/dsl is targeted for? Q2 or H2?
l
I'm running into a problem with both Dokka 1.9.10 and 1.9.20, after adding Lottie Compose 6.4.0 to my project. Kotlin 1.9.22 AGP 8.3.0 Gradle 8.6 sourceCompatibility, targetCompatibility and Kotlin JVM target all set to Java 11.
Copy code
ERROR: Exception while analyzing expression at (238,45) in /runner/work/app-path-redacted/AppComposeScreen.kt
...
Caused by: java.lang.IllegalStateException: Could not read class: VirtualFile: /home/automata/.gradle/caches/transforms-4/ec27e9b5bc98114d7404e1026e605152/transformed/lottie-compose-6.4.0-api.jar!/com/airbnb/lottie/compose/LottieCompositionSpec.class
...
Caused by: java.lang.UnsupportedOperationException: PermittedSubclasses requires ASM9
Maybe it's related to this one? https://github.com/Kotlin/dokka/issues/2956
The line coordinates at which Dokka fails to analyze is an extension of 
PreviewParameterProvider
and doesn't mention any class related to Lottie Compose (the class is mentioned at another point of the file, inside a private Composable).
i
> I was hoping to see Dockatoo in this release so I don't have to try integrating w/ that temporarily 🙂 > Any rough idea on when the new gradle plugin/dsl is targeted for? Q2 or H2? > We want to make sure that the DSL we release 1) is not going to change for a while, to avoid double migration; 2) solves usability problems we uncovered during UX interviews. And this takes quite a bit of time, unfortunately :( We're aiming to ship a Beta/RC of the plugin around Kotlin 2.0, to test it and give people time to migrate gradually, with the full release and switch planned for 2.1
👍 1
thank you color 1
@Lukasz Kalnik can you make sure that Dokka is indeed 1.9.10/1.9.20, and no older version ends up in the dependencies? We have compatibility tests with Java 21 (plus it's using Kotlin 1.9.22), and everything seems to work fine, so my bet is that Android is somehow interweaving This could be the first step:
Copy code
./gradlew buildEnvironment
l
Copy code
classpath
+--- org.jetbrains.dokka:dokka-gradle-plugin:1.9.10
|    \--- org.jetbrains.dokka:dokka-core:1.9.10
|         +--- org.jetbrains.kotlinx:kotlinx-coroutines-core:1.6.3
|         |    \--- org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.6.3
...
i
Oh, and what task are you using to run Dokka? 
dokkaHtml
/ 
dokkaHtmlMultiModule
?
l
dokkaHtml
Hmm, although if I just run 
./gradlew dokkaHtml
from the command line it generates the docs correctly. Must be something with our CI configuration then. Thanks for the quick help though!
kodee naughty 1
o
Could you also provide a full StackTrace of the exception? And also, in which specific task the error is happening on CI? AGP also embeds Dokka of older version and executes it under the hood via some tasks (F.e in the issue above, there is ‘javaDocReleaseGeneration’ task which fails)
l
That's how we configure Dokka in our 
build.gradle.kts
Copy code
tasks.dokkaHtml.configure {
    dokkaSourceSets {
        named("main") {
            noAndroidSdkLink.set(false)
        }
    }
}

tasks.register<Jar>("javadocJar") {
    archiveClassifier.set("javadoc")
    from("$buildDir/dokka/javadoc")
}

artifacts {
    tasks.findByName("javadocJar")
}

    publishing {
        singleVariant("release") {
            withJavadocJar()
        }
Yes, in my CI also the 
javaDocReleaseGeneration
fails
I put the full stack trace into a gist. And thank you for your quick reaction! https://gist.github.com/lukaszkalnik/a00133895220d6067b30ac926b71bfdb
Interestingly, the javaDocGeneration worked until we introduced the Lottie Compose 6.4.0 Library into our project.
o
Okay, then if it's 
javaDocReleaseGeneration
which fails - then it's Dokka running, but older version coming from AGP - and so it's an issue on AGP side unfortunately... May be you can workaround somehow like this (https://github.com/getkevin/kevin-android/pull/121/files) - workaround means, that there will be no 
javadoc.jar
generated via AGP
l
That's kind of the point why we run dokka, to create 
javadoc.jar
We release a library without sources, and javadoc.jar is the only documentation for our library users.
o
The problem is, that it's not the latest Dokka which is failing, but the one that is embedded in AGP and Im not sure it's possible to update version of it So to overcome this, I can propose to disable javadoc generation via AGP (by removing 
withJavadocJar
in 
publishing
DSL coming from AGP) and manually add 
javadoc.jar
generated by latest Dokka to publication I will setup some test project and come back to you later today with some snippet to overcome the issue
l
Amazing, that would be a great help. I appreciate it.
👍 1
Thanks to your hints I managed to solve the problem. Like you said, in the AGP's 
publishing
DSL I removed the 
withJavaDocJar()
and instead in Kotlin's 
publishing
DSL I added to each of the 
publications
an 
artifact()
containing the Jar generated from Dokka output.
o
Cool! that's what I had in mind. I will still create an example with this workaround (and may be will found another) and post in the issue, so there will be single place for where to look 🙂
thank you color 2
l
Amazing!
13 Views
Open in Slack
PreviousNext
Powered by