Collection has more than one element in DefaultDocumentableMerger.mergeExpectActual$analyzeExpectActual
#3900
Labels
Comments
|
Seems to be fixed with #3875 . Was that fix released? |
ShreckYe
added a commit
to huanshankeji/compose-multiplatform-material
that referenced
this issue
Nov 6, 2024
…adapted from "gradle-common", and resolve heap memory issues A source commit: huanshankeji/gradle-common@c1c69c3 `java.lang.OutOfMemoryError: Java heap space` occurs when running the `dokkaGenerate` Gradle task without further configuration and is resolved with the approach from Kotlin/dokka#3885 (comment). The solution code `dokkaGeneratorIsolation = ClassLoaderIsolation()` has to be added to the subproject build scripts (the convention plugin) to work. Moreover, this happens when the heap space is not enough: ```text The Daemon will expire immediately since the JVM garbage collector is thrashing The project memory settings are likely not configured or are configured to an insufficient value. The memory settings for this project must be adjusted to avoid this failure. These settings can be adjusted by setting 'org.gradle.jvmargs' in 'gradle.properties'. The currently configured max heap space is '2 GiB' and the configured max metaspace is 'unknown'. ``` Therefore, `Xmx` in `org.gradle.jvmargs` is increased all the way to 32 GB. 4 GB and 8 GB still cause GC thrashing, and 16 GB is enough but the task takes more time compared to 32 GB with swap. The actual max memory usage is about 30 GB with the 32 GB max heap size. This seems to be caused by parallelism so to reduce the max memory usage, the `--max-workers` Gradle argument can be used and is tested to work. `--no-parallel` doesn't make a difference as tested, however. Eventually, after the 2 issues above are fixed, the task still fails because of Kotlin/dokka#3900.
Nek-12
added a commit
to respawn-app/FlowMVI
that referenced
this issue
Nov 6, 2024
Not yet, but it will be included in 2.0.0 |
|
This a little bit late for us (I'm assuming 2+ weeks) because the entire documentation is not available and rolling back is difficult. If it's not hard for you, can this be published as Beta2? If not, let me know so that I can take action on my end. Alternatively, if there's a workaround, I can try and apply it. |
|
Yeah, sorry for the inconvenience, I understand. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To Reproduce
I'm not sure how to reproduce. This is a regression.
Details
respawn-app/FlowMVI@f43b22b
Dokka configuration
Configuration of dokka used to reproduce the bug
plugins { id("org.jetbrains.dokka") // id("org.jetbrains.dokka-javadoc") } val libs by versionCatalog dokka { dokkaGeneratorIsolation = ClassLoaderIsolation() moduleName = project.name moduleVersion = project.version.toString() pluginsConfiguration.html { footerMessage = "© ${Config.vendorName}" customAssets.from(rootDir.resolve("docs/images/icon-512-maskable.png")) homepageLink = Config.url } dokkaPublications.configureEach { suppressInheritedMembers = false suppressObviousFunctions = true } dokkaSourceSets.configureEach { reportUndocumented = true enableJdkDocumentationLink = true enableAndroidDocumentationLink = true enableKotlinStdLibDocumentationLink = true skipEmptyPackages = true skipDeprecated = true jdkVersion = Config.javaVersion.majorVersion.toInt() } // remoteUrl = Config.docsUrl } dependencies { dokkaPlugin(libs.requireLib("dokka-android")) }Installation
This seems to be related with the complicated overload family for some functions in the :core module
The text was updated successfully, but these errors were encountered: