Skip to content

experiment: isolate whether Dokka 2.2.0 breaks the CodeQL Kotlin extractor - #524

Closed
zantvoort wants to merge 3 commits into
mainfrom
codeql-experiment-dokka
Closed

experiment: isolate whether Dokka 2.2.0 breaks the CodeQL Kotlin extractor#524
zantvoort wants to merge 3 commits into
mainfrom
codeql-experiment-dokka

Conversation

@zantvoort

Copy link
Copy Markdown
Collaborator

Throwaway, do not merge. Closes as soon as CodeQL reports.

#523 reverted two things together because I could not separate them cheaply. This puts back exactly one of them, Dokka 2.2.0 in the Ktor modules, with <extensions>true</extensions> left in place.

  • CodeQL red: Dokka is the culprit, and the plugin-extension cleanup can be kept.
  • CodeQL green: Dokka is innocent, the extension flag is what the extractor needs, and Dokka 2.2.0 can be kept along with the metadata fix it brings.

…deQL

CodeQL's java-kotlin analysis has failed on every build since Dokka moved
to 2.2.0 in the Ktor modules. Its autobuild runs

  mvnw clean package -Dmaven.javadoc.skip -DskipTests ...

and the reactor reaches storm-ktor, where Dokka 2.2.0 loads a Kotlin 2.2
analysis into the Maven JVM, and then storm-kotlin-test, whose kapt runs
on Kotlin 2.0.21. CodeQL's extractor is injected into that compilation as
a compiler plugin and is now bound against the wrong generation:

  The provided plugin com.github.codeql.KotlinExtractorComponentRegistrar
  is not compatible with this version of compiler.
  java.lang.AbstractMethodError: ... does not define or inherit an
  implementation of the resolved method registerProjectComponents ...

The green build before it ran Dokka 2.0.0 at the same point, in the same
order, under the same CodeQL, and the same kapt succeeded.

Dokka is this project's javadoc, so it now honours the switch that says a
build wants none. The scan asked for no documentation and gets none, which
keeps a documentation engine's Kotlin out of the JVM that is compiling
Kotlin. Releases and the docs workflow do not set the property, so they
still produce the javadoc jar Maven Central requires.

Only the two Ktor modules opt in, since they are the only ones whose Dokka
runs a different Kotlin generation than the reactor compiles with.
…with

The tidy-up in the previous change broke CodeQL's java-kotlin analysis on
every build since, and skipping Dokka's output was not enough: the mojo
returns early but its plugin realm is still loaded, and the failure
reproduced unchanged. Rather than leave the analysis red while narrowing
which half of that tidy-up is responsible, both halves go back.

The Ktor modules return to Dokka 2.0.0, the generation the rest of the
framework runs, and the three modules that declared the Kotlin plugin as
a build extension declare it that way again. Both carry a comment saying
what they cost and why they stay: Dokka 2.0 reports metadata errors it
cannot read for a Kotlin 2.3 module, and the extension synthesises
duplicate compile and kapt executions.

What stays from the tidy-up is what cannot affect the extractor: Dokka's
source root is still named explicitly, so a module with no src/main/java
does not report a missing directory, and Dokka now honours
maven.javadoc.skip, so a build that asks for no documentation gets none.
@zantvoort

Copy link
Copy Markdown
Collaborator Author

Answered: green. Dokka 2.2.0 is innocent; the <extensions>true</extensions> removal is what broke the extractor. Folding the finding into #523.

@codecov

codecov Bot commented Aug 22, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant