We are getting a few errors when generating docume...
# dokka
l
We are getting a few errors when generating documentation for some special java classes. This is all confined within one package which I would like to exclude from documenting entirely. I tried excluding it using
perPackageOption
but the exception still occurs. I got it to work by “avoiding” the folder by adding all folders but this one to
sourceRoots
but this is very tedious as I need to list all manually. Is there a way to exclude a folder from dokka completely?
1
m
Could you share how did you exclude this package from documentation? I think that suppressing it should do the trick
l
Copy code
sourceRoots.setFrom(file("src/main/java/com/a/b/c"))
            sourceRoots.from(file("src/main/java/com/a/b/d"))
            sourceRoots.from(file("src/main/java/com/a/b/e"))
This works as it actually excludes the folders.
this does not work as the model for the package still seems to be built anyways:
Copy code
perPackageOption {
                    matchingRegex.set("com.a.b.e")
                    suppress.set(true)
                }
m
i think it is the case because the
matchingRegex
matches packages not directories (and in kotlin you can have packages in weird directories that don’t match them). I don’t know how you name your packages but something like
<http://java.com|java.com>.a.b.c
might work
l
Sorry, this was a copy paste error. I have it with dot annotation.
I updated it.
If I do not even add the source root, it works. If not ,I get this exception:
> Couldn't get delegate for class
and I have no clue which of the 100 classes causes it. 😔
k
If you set your sources manually then I guess you will be getting
ERROR CLASS
and other unresolved stuff if you didn’t set up classpath in dokka properly
l
Yes, I get these errors. Kinda out of ideas how I can solve this. 😟
How could I set up the classpaths? Would that be an option? 🤔
m
I think that firstly we should actually try to tell why you can’t document this package. Is it possible for you to share your project with us? Or some reproducable sample?
k
There is a configuration option in Dokka called
classpath
in each Dokka source set
But the question is - why do you need to set them up manually at all?
l
I think my employer would not be happy if I share the source. 😀 I am trying to create a mini sample but I am heaving a hard time as the stack trace does not indicate where this happens:
Copy code
Caused by: org.jetbrains.kotlin.utils.KotlinExceptionWithAttachments: Couldn't get delegate for class
	at org.jetbrains.kotlin.asJava.builder.LightClassDataHolderKt.findDelegate(LightClassDataHolder.kt:103)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataHolder$ForClass$findDataForClassOrObject$1.invoke(LightClassDataHolder.kt:40)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataHolder$ForClass$findDataForClassOrObject$1.invoke(LightClassDataHolder.kt:34)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataHolderImpl.findData(LightClassDataHolder.kt:86)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataHolderImpl.findData(LightClassDataHolder.kt:82)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataHolder$ForClass$DefaultImpls.findDataForClassOrObject(LightClassDataHolder.kt:40)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataHolderImpl.findDataForClassOrObject(LightClassDataHolder.kt:82)
	at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration.findLightClassData(KtLightClassForSourceDeclaration.kt:108)
	at org.jetbrains.kotlin.asJava.classes.KtLightClassForSourceDeclaration.getLightClassData(KtLightClassForSourceDeclaration.kt:106)
	at org.jetbrains.kotlin.asJava.classes.KtLazyLightClass.getOwnMethods(KtLazyLightClass.kt:29)
	at org.jetbrains.kotlin.asJava.classes.KotlinClassInnerStuffCache.getAllMethods(KotlinClassInnerStuffCache.kt:150)
	at org.jetbrains.kotlin.asJava.classes.KotlinClassInnerStuffCache.access$getAllMethods(KotlinClassInnerStuffCache.kt:27)
	at org.jetbrains.kotlin.asJava.classes.KotlinClassInnerStuffCache$_getMethods$2.invoke(KotlinClassInnerStuffCache.kt:91)
	at org.jetbrains.kotlin.asJava.classes.KotlinClassInnerStuffCache$_getMethods$2.invoke(KotlinClassInnerStuffCache.kt:27)
	at org.jetbrains.kotlin.asJava.classes.KotlinClassInnerStuffCache$get$1$holder$1$1.compute(KotlinClassInnerStuffCache.kt:36)
	at com.intellij.psi.impl.PsiCachedValueImpl.doCompute(PsiCachedValueImpl.java:54)
	at com.intellij.util.CachedValueBase.lambda$getValueWithLock$1(CachedValueBase.java:235)
	at com.intellij.openapi.util.RecursionManager$1.doPreventingRecursion(RecursionManager.java:117)
	at com.intellij.openapi.util.RecursionManager.doPreventingRecursion(RecursionManager.java:75)
	at com.intellij.util.CachedValueBase.getValueWithLock(CachedValueBase.java:236)
	at com.intellij.psi.impl.PsiCachedValueImpl.getValue(PsiCachedValueImpl.java:43)
	at org.jetbrains.kotlin.asJava.classes.KotlinClassInnerStuffCache$get$1.computeValue(KotlinClassInnerStuffCache.kt:41)
	at org.jetbrains.kotlin.asJava.classes.KotlinClassInnerStuffCache$get$1.getValue(KotlinClassInnerStuffCache.kt:65)
	at org.jetbrains.kotlin.asJava.classes.KotlinClassInnerStuffCache.get_getMethods(KotlinClassInnerStuffCache.kt)
	at org.jetbrains.kotlin.asJava.classes.KotlinClassInnerStuffCache.getMethods(KotlinClassInnerStuffCache.kt:94)
	at org.jetbrains.kotlin.asJava.classes.KtLightClassBase.getMethods(KtLightClassBase.kt:40)
	at org.jetbrains.dokka.base.translators.psi.DefaultPsiToDocumentableTranslator$DokkaPsiParser$parseClasslike$2$invokeSuspend$$inlined$with$lambda$2.invoke(DefaultPsiToDocumentableTranslator.kt:186)
	at org.jetbrains.dokka.base.translators.psi.DefaultPsiToDocumentableTranslator$DokkaPsiParser$parseClasslike$2$invokeSuspend$$inlined$with$lambda$2.invoke$default(DefaultPsiToDocumentableTranslator.kt:166)
	at org.jetbrains.dokka.base.translators.psi.DefaultPsiToDocumentableTranslator$DokkaPsiParser$parseClasslike$2.invokeSuspend(DefaultPsiToDocumentableTranslator.kt:199)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
	at kotlinx.coroutines.internal.ScopeCoroutine.afterResume(Scopes.kt:32)
	at kotlinx.coroutines.AbstractCoroutine.resumeWith(AbstractCoroutine.kt:113)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:46)
	at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
	at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:571)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:738)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:678)
	at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:665)
m
You can add debugger breakpoint on this exception and read it from there
l
That sounds interesting. How would I do that? 🤔
m
build your project with gradle property:
org.gradle.debug=true
in (gradle.properties file). Then run your dokka task and (in intellij) add remote configuration (with default settings) and create a breakpoint on the exception (there should be a tab in the bottom-left part of the screen with debug)
l
I will try my luck, thanks for the input. 🙂
This just made my live so much easier. I actually managed to figure out the file. But it is a 4 layer kotlin -java - kotlin -java hierarchy with nested classes. Once I try to extract all that to a separate project and clean it, the exception is not reproducible. 🙈
These classes are private and will not be documented anyways, so there is actually no reason to parse them. Is there any way to just exclude that single file completely? 🤔
I managed to reproduce it with a minimal sample. 🦜 I created an issue for it here: https://github.com/Kotlin/dokka/issues/1735 Again, thanks for all the help!
m
Nice, thanks! I’ll take a look today
l
To be fair, this is a rather specific constellation. 😅