I'm trying to override the `<head>` of the HTML format.
I see I can do:
```dokka {
pluginsConfigur...
c
CLOVIS
11/30/2025, 5:49 PMI'm trying to override the
<head> Copy code
dokka {
pluginsConfiguration.html {
templatesDir.set(file("docs/dokka/overrides"))
}
}o
Oleg Yukhnevich
12/01/2025, 9:31 AMHm, yes. You need to apply this configuration to all projects where Dokka is configured, as Dokka will first generate "partial" HTMLs for each project and only then aggregate them into a multi-module HTML output.
c
CLOVIS
12/01/2025, 9:37 AMThat's very inconvenient. I can't add this line to a convention plugin because it wouldn't have access to the file (the convention plugins are in another repo) and it must be file so I can't just bundle it in the convention plugins.
So what I have to do:
ā¢ Bundle the file in the convention plugin
ā¢ Create a task that reads from the plugin resources and creates the templates directory
ā¢ Configure Dokka to that directory
Is that right?
That also means I won't be able to update that value without republishing the configuration plugins etc.
o
Oleg Yukhnevich
12/01/2025, 9:57 AMYeah, if the convention plugins are in a separate repo, it might be inconvenient, and what you are suggesting is an option.
I see multiple solutions/ideas here, based on the fact that you have those convention plugins in a separate repository for a reason.
1. If you want all your other projects to have the same configuration and templates, then yes, the best way to go is to bundle those templates. In this case, I don't really see why in that case, you might want to update the templates separately per project (feel free to add more context here)
2. If you want your projects to have different templates, but the same configuration, I do have two options:
a. You can define some explicit directory, like
rootProjectDir.resolve("dokka-templates")a
Adam Semenenko
12/01/2025, 10:03 AMmaybe he also has some ideas here that don't involve Dokka's re-architectureIf I could re-implement DGP I would stop generating the modules in the individual subprojects. Instead DGP would ship the raw materials (locations of source files, classpaths, etc) to the aggregating project and then the configuration can be applied once and consistently. DGP would lose the 'locality' of module-specific configuration, but it would be easier to solve problems like this. We can probably do this as part of KDoc machine-readable representation. Each subproject would expose the analysed data, and the aggregated project could focus on the front-end configuration.
ā 1
c
CLOVIS
12/01/2025, 10:08 AM1. If you want all your other projects to have the same configuration and templates, then yes, the best way to go is to bundle those templates. In this case, I don't really see why in that case, you might want to update the templates separately per project (feel free to add more context here)I do want all of them to have the same configuration (at least, to my current knowledge). However, that configuration might change over time, and I have a three-tier configuration (convention plugin in a repo ā the baseline repo ā each project repo) so having it in the configuration plugin makes changes very slow. For this specific example, maybe I can live with it.
š 1
CLOVIS
12/01/2025, 10:11 AMDGP would lose the 'locality' of module-specific configuration, but it would be easier to solve problems like this.Intuitively, I would expect that module-specific configuration affects the contents (e.g. hide private members) and aggregation-wide configuration affects the rendering (e.g. the logo, the page title, etc)
agree 1
o
Oleg Yukhnevich
12/01/2025, 10:20 AMYes, I agree, and this is one of the reasons behind KDoc's machine-readable representation: it provides better separation between the "analysis" and "rendering" parts. It should also help with other endeavors, such as MkDocs (Zensical?), docusaurus, or other integrations.
Stay tuned for future updates in this regard š
š 1