-
Notifications
You must be signed in to change notification settings - Fork 409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix DGP/KMP integration, so Dokka can 'see' code from shared source sets in target source sets #3814
Fix DGP/KMP integration, so Dokka can 'see' code from shared source sets in target source sets #3814
Conversation
…ndents # Conflicts: # dokka-runners/dokka-gradle-plugin/src/main/kotlin/internal/uriUtils.kt
- Filter out legacy KMP metadata compilations (they were retained to support Dokka v1). - Fetch both `jar` and `android-classes-jar` from AGP (probably not necessary, but why not?) - Only use `compilation.compileDependencyFiles` in non-AGP projects. - Add more docs
…ntion set in KotlinAdapter
- implement new JUnit extension to help set up and re-run DGP integration tests with different versions
…ses, tidy Android projects, fix suppress/analysisPlatform defaults.
`fileTree.kt` contains a utility for logging pretty file trees, which is useful in providing human-readable context for test failures. This PR updates the utility to only use NIO Path, rather than the older `java.io.File`. This change was split off from #3814 to make the PR smaller
`fileTree.kt` contains a utility for logging pretty file trees, which is useful in providing human-readable context for test failures. This PR updates the utility to only use NIO Path, rather than the older `java.io.File`. This change was split off from #3814 to make the PR smaller
…ndents # Conflicts: # .gitattributes # build.gradle.kts # dokka-integration-tests/gradle/build.gradle.kts # dokka-runners/dokka-gradle-plugin/src/main/kotlin/tasks/DokkaGenerateTask.kt # dokka-runners/dokka-gradle-plugin/src/testFixtures/kotlin/GradleTestKitUtils.kt # dokka-runners/dokka-gradle-plugin/src/testFixtures/kotlin/fileTree.kt
- Filter out metadata compilations when determining the source set target. - Remove KotlinPlatform warning - it's always triggered for commonMain. - Fetch _all_ dependent source sets, including transitives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Changes to defaults are looks logical for me, only the test placement worries me :)
dokka-runners/dokka-gradle-plugin/src/main/kotlin/adapters/KotlinAdapter.kt
Show resolved
Hide resolved
dokka-runners/dokka-gradle-plugin/src/testFixtures/kotlin/kotestFiles.kt
Show resolved
Hide resolved
import kotlin.io.path.walk | ||
|
||
@Ignored("KMP: References is not linked if they are in shared code and there is an intermediate level between them https://github.com/Kotlin/dokka/issues/3382") | ||
class KmpCommonSourceSharedWithDependentsTest : FunSpec({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this test should be placed into dokka-integration-tests
so that we will be able to check it with different Kotlin versions.
In my understanding, functional tests
in DGPv2 are more about plugin behavior while this test is more about overall Dokka behavior and so should be in IT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would probably except here a test which checks that we set correct defaults for DokkaSourceSetSpec platform, dependsOn and etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this test should be placed into
dokka-integration-tests
Good idea, done.
Could you check the expected data in dokka-integration-tests/gradle/projects/it-kotlin-multiplatform/expectedData/html
? There are errors, but I'm not sure if any are DGP's responsibility, or are caused by #3382
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, it doesn't look like TeamCity likes the KMP IT. Some of the tests are failing.
https://ge.jetbrains.com/s/ndo3qeb66whvy/tests/overview?outcome=FAILED
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmmmm it looks like locally I get Error type: Unresolved type for NativeMainCls
, but not on TeamCity?? Why??
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The difference in OS (linux vs macOS) and so probably the difference is in dependencies passed inside KGP. E.g iOS
targets are not compilable on linux and so probably the classpath (or some other configuration) is somehow different, which causes this behavior.
In this case, I think that for this test probably having just linux
targets should be enough to reproduce the issue, correct?
We could also try to add mingw
target (or androidNative
targets), or add additional intermediate sourceSets somewhere, so that all targets will be cross-compiled on all OSs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could understand it if locally, on my Mac, I would get no errors and on Linux the macOS targets would cause Unresolved type
errors, but I don't see why it's the other way around. I'd like to understand the problem more before trying to work around it, but I'm not sure how.
I'll check with my team.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that it's better to compare configurations on CI (linux) vs on macOS and then think about what could go wrong.
Also, I would propose in any case add second targets for iOS and linux, as Dokka doesn't work well with single target source sets - may be it could be also cause difference in produced configuration in this case.
E.g, we have an issue with K2: #3386, may be something similar also exists in K1.
Again, the first step will be to obtain configuration used to run Dokka and compare them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From looking at the Dokka configuration, it looks correct (both locally and on TeamCity), so I'm going to chalk the failures up to issues with K1 analysis and disable the HTML output validation tests. They're not critical for this PR anyway.
…src-to-dependents
…to integration test, to support testing different KGP versions
31d28b3
to
b58d42f
Compare
There are 3 main fixes in this PR:
KotlinAdapter#determineKotlinPlatform
). Filter out metadata targets (they're not relevant for target determination), and only fall back toKotlinPlatform.Common
if necessary.compilation.konanTarget.name
instead ofcompilation.target.name
.jar
andandroid-classes-jar
dependencies. For KGP projects, usecompileDependencyFiles
.The remaining changes are to support these fixes:
convention()
to set default values.Should fix KT-70857