Empty publication when Kotlin plugin applied to subprojects, but not to root project (with apply=false) #123
Comments
|
Hey @CLOVIS-AI, thanks for the report. I appreciate you using Dokkatoo, and taking the time to improve it. I had a look through the code and I couldn't see anything obviously wrong. It's certainly not helpful that the localhost link to index.html 404s - I'll add a check to fix that. My only guess is that since I have some more questions to help investigate.
|
If I run
In all cases: $ tree build/dokka
build/dokka
└── html
└── coreIn the first and third case, The most obvious difference I see is that the executions that expose the website correctly have: Could it be that the root project just doesn't find the
I assume you mean Worker log
Yes. The last commit where it did work was f3759626465ad8f3839a1b6a36205002d06bdfcb. It's hard to provide a diff, because the only thing that changed is the convention plugins being extracted to another repository. You can find the code for the convention plugins in gradle/conventions. They are essentially the same. Most importantly, they use the same version of Dokkatoo (2.0.0). |
|
I managed to reproduce the issue using the sample in the convention plugin repository directly. This is more convenient, because it allows editing the plugins to try fixes. To reproduce:
Asking Gradle to dump dependencies, I get which is the same as what I get with the old version (which worked). So, at least, it's not the |
|
Interesting, I managed to reproduce the issue in a project that does not use the convention plugins at all (by simply inlining them), see the branch I'm currently diff-ing it with the version that works. |
|
Uh, found the problems. Incorrect fix for #14Incorrect: dependencies {
// This is required at the moment, see https://github.com/adamko-dev/dokkatoo/issues/14
dokkatoo.versions.jetbrainsDokka.map { dokkaVersion ->
"org.jetbrains.dokka:all-modules-page-plugin:$dokkaVersion"
}
}
Correct: dependencies {
// This is required at the moment, see https://github.com/adamko-dev/dokkatoo/issues/14
dokkatooPluginHtml(
dokkatoo.versions.jetbrainsDokka.map { dokkaVersion ->
"org.jetbrains.dokka:all-modules-page-plugin:$dokkaVersion"
}
)
}This lets Dokkatoo generate the output, but it only has the main page decorations, it doesn't actually contain the documentation of the The root project must have the Kotlin pluginEven if For the first problem, well, an issue already exists. For the second problem, could you please add some kind of error when Dokkatoo is applied without the Kotlin plugin, since apparently it breaks the output? After that, I guess this issue is fixed. |
|
Completely unrelated, but thanks for the great plugin! Essentially all my projects have migrated to it :) |
|
Thanks for the praise! I'm happy Dokkatoo is working out well for you! I've had a bit of a further dig into the issues. localhost link to index.html 404sI've had an experiment of trying to disable the logging if the index.html file doesn't exist, or logging a warning if the URL 404s, and a few other ideas. And to be honest, I don't really feel like they worked well. It felt a bit janky, and over bearing, and sensitive. A 404 might be caused by index.html missing, but also maybe the webserver might be broken, or the URL is invalid. Trying to put some sort of warning in is a nice idea, but I'm thinking it's basically the same as the link 404ing, so adding a warning is redundant. Maybe I could add a check in the 'generate HTML publication' task where if the index.html file isn't generated then it logs a warning, but again, it doesn't quite sit right with me. I'm not quite sure why, but I think it's because it just leads to more code and tests and things to go wrong! In any case, at least my experiments mean I've added some basic tests! The root project must have the Kotlin pluginAh yes, this is something I've noticed before, but I didn't make an issue for it. Alternatively the plugin can be added to dokkatoo/buildSrc/build.gradle.kts Line 10 in 1a73111 I'm not sure this is a Dokkatoo problem, or a Gradle problem. The buildscript classpath is weird stuff. WDYT? |
|
I wonder if there is a way to ask Gradle whether a plugin is on the classpath, and emit a warning if it isn't? That's a pretty big footgun, and it's really not easy to debug. |
Welcome to Gradle :) Apparently is the 'plugin must be applied to the root project' is a Gradle problem, so I made an issue here gradle/gradle#27218 I can certainly add a warning though. Something like val kotlinExtension = project.extensions.findKotlinExtension()
if (kotlinExtension == null && project.extensions.findByName("kotlin") != null) {
logger.warn("$dkaName could not get the Kotlin extension in ${project.path}")
}in DokkatooKotlinAdapter |
aSemy
changed the title
Hi!
I have a project in which I applied the Dokkatoo plugin. I'm currently refactoring it to use convention plugins, and in the process something strange broke. I don't know how to debug it.
The project is structured as follows:
The
:coreproject has Dokkatoo. The:appproject doesn't. The root project has a dependency on:core.Previously, I ran
./gradlew :dokkatooGeneratePublicationHtmlto generate the HTML output. However, now, it only generates an emptybuild/dokka/coredirectory.If I run
./gradlew dokkatooGenerate, I get the following link printed in the terminal:http://localhost:63342/playground/build/dokka/html/index.html. Opening that link in the browser does allow me to browse the generated documentation. However, that file doesn't exist. Thebuild/dokkadirectory only contains a subdirectory calledcore, there are no other files.What could be the cause? I don't understand how this can happen.
Reproduction:
6d3edba36598d9d4d1fc1e5906bf6be1f6b698d3Other useful links:
opensavvyConventions.plugins.baseconvention plugin: here (unrelated to Dokka)opensavvyConventions.plugins.rootconvention plugin: here (applies the plugin + the dependencies workaround)opensavvyConventions.plugins.kotlin.libraryconvention plugin: here (applies the plugin + configures the project name + includes the README, etc)The text was updated successfully, but these errors were encountered: