[rcombs]

Upgrade the wrapper to Gradle 8.14.6 and the Kotlin/Dokka build plugins so this stage supports Java 11 through 24. Target Java 11 bytecode, use the host Gradle Kotlin runtime, and preserve Markdown API documentation generation.

Stock wrapper files, functional build changes, case-conversion cleanup, functional tests, CI, and documentation remain separate commits. This stage is independently usable without the later automatic wrapper selection.

Validation

Build and compatibility checks passed on Java 11, 14, 15, and 24.

🤖 Codex

[astiob]

I think it might make more sense to have “Refresh stock wrapper files for Gradle 8.14.6” in the same commit as gradle-wrapper.properties updates. Or perhaps have them swapped, based on this fragment of Gradle docs:

Note that running the wrapper task once will update gradle-wrapper.properties only, but leave the Wrapper itself in gradle-wrapper.jar untouched.

This is usually fine as new versions of Gradle can be run even with older Wrapper files.

If you want all the Wrapper files to be completely up-to-date, you will need to run the wrapper task a second time.

which suggests that having an older JAR with a newer version in the properties file is normal but says nothing about the opposite.

[astiob]

Nit, but I’d rather have one of the following:

1. Move the plugin declaration all the way up to immediately after the plugins block, and move the dependency line inside the existing dependencies block. This avoids having two blocks of dependencies.

2. It seems this isn’t how the legacy Dokka format plugins are supposed to be registered at all. The way I see officially documented at https://github.com/Kotlin/dokka/blob/v2.2.0/dokka-subprojects/plugin-gfm/README.md is this monstrosity:

   // Dokka v2 ships HTML/Javadoc formats; retain the existing Markdown output too.
   @OptIn(InternalDokkaGradlePluginApi::class)
   abstract class DokkaGfmPlugin : DokkaFormatPlugin("gfm") {
       override fun DokkaFormatPlugin.DokkaFormatPluginContext.configure() {
           project.dependencies {
               dokkaPlugin(dokka("gfm-plugin"))
           }
       }
   }
   apply<DokkaGfmPlugin>()

   with an additional import org.jetbrains.dokka.gradle.internal.InternalDokkaGradlePluginApi

   (and with the add("dokkaGfmPlugin", "org.jetbrains.dokka:gfm-plugin:2.2.0") invocation removed).

   This avoids relying on knowledge of Dokka’s internal configuration and artifact naming (and removes an opportunity for an accidental version conflict), but then this explicitly taps into an “internal API”, so I’m guessing it’s gonna be potentially fragile either way. But at least this is suggested in the official readme, so maybe this will be more reliable or at least easier to adapt in the future if they do change the API? It might be a good idea to add a link to the readme from where this is sourced, too, so that any future changes can be more easily copied from the same source.

   For reference, it appears to me that this does something extra compared to the add("dokkaGfmPlugin"...) line, but I can’t tell if the extra actually matters at all.

[astiob]

You may wanna update this URL to point to TypesettingTools/SubKt instead of Myaamori/SubKt while you’re at it.

[astiob]

By the way: all new build.gradle.kts code in your entire PR stack seems to use .set(...). If I understand correctly, simple assignment = works equally well. Simple assignment is visually simpler and more consistent with other code that remains in build.gradle.kts, so I’d prefer that to be used if it works.

[astiob]

It would be nice to add a blank line before the testImplementation dependencies to separate the different kinds of dependencies.

[astiob]

Note to maintainers: README will need to be updated (in several places) upon release.