Seventeen Kotlin libraries in forty-five published modules, under io.github.softistx:stx-* — a Ktor and Spring Boot foundation, Postgres and MongoDB, Redis, Kafka and AMQP, object storage, GraphQL, workflows that survive a restart, schema migrations, telemetry, i18n, and a Compose Multiplatform component library. Each one publishes as its own artifact, with its framework integration beside it, so depending on stx-jpa drags in neither Ktor nor Spring.

They are built with the JetBrains Kotlin Toolchain (the kotlin CLI, formerly Amper) — no Gradle, no Maven, no gradlew. A module is a directory with a module.yaml, registered by path in project.yaml. Consuming them needs none of that: they are ordinary Maven artifacts with Gradle metadata, and docs/consuming.md has the snippet for Gradle, Maven and the toolchain.

Alongside the libraries is an OpenAPI-to-Kotlin client generator, built as four modules that form one chain:

examples/demo-api/openapi.yaml     one document
        │
libs/api/stx-openapi-generator         reads it, emits models and a typed client (KotlinPoet)
        │
plugins/openapi                wraps the generator as a toolchain build task
        │
examples/demo-client               a Ktorfit client, kotlinx.serialization  ─┐
examples/demo-spring-client        a Spring @HttpExchange client, Jackson 3 ─┴─ both call examples/demo-api

Two generated clients drive one hand-written server over real HTTP, so a disagreement between the two serialization libraries about what the document means fails a test rather than shipping.

examples/jpa-shop is separate from that chain: a Ktor catalogue over Postgres showing stx-jpa's CRUD extensions, transaction guard and audit layer end to end. So is examples/graphix-shop, a Ktor GraphQL catalogue over stx-graphix-ktor, examples/graphix-codegen, the two GraphQL codegen plugins on one schema, and examples/material-demo, the catalogue for the UI library — ./kotlin run -m md-desktop.

Alongside them are the shared service libraries, which have nothing to do with the generator:

dependencies {
    implementation("io.github.softistx:stx-jpa:0.2.1")
    implementation("io.github.softistx:stx-jpa-ktor:0.2.1")
}

On Maven Central — no repository block, no token, PGP-signed, with a sources jar. docs/consuming.md has the Maven and Kotlin Toolchain forms, and which artifact you actually want: a library and its framework integration are separate, so depending on stx-jpa drags in neither Ktor nor Spring.

Each library family has its own version. A library and its framework integrations — stx-jpa, stx-jpa-ktor, stx-jpa-spring — are one release line and move together; separate libraries do not. So a bump you see is a bump that concerns you. docs/consuming.md says what that promises, and the one thing it does not. Everything through 0.2.1 was released in lockstep; from there each family moves on its own.

For working on the libraries rather than with them. You need no JDK and no Kotlin compiler — the wrapper provisions both.

./kotlin build          # compile everything
./kotlin test           # run every module's tests
./kotlin show modules   # module names accepted by -m

Use ./kotlin, not a bare kotlin: the wrapper pins the toolchain version. CONTRIBUTING.md is the rest.

Pull requests target develop, never main. Anything touching libs/ needs a changeset (bun changeset) and a publish to mavenLocal before a consumer is built against it — CONTRIBUTING.md explains why that second step is the one that catches a broken POM. Be civil: Code of Conduct.

Found a vulnerability? Not an issue — SECURITY.md.

Apache-2.0. Third-party documentation cached under .agents/skills/*/references/ is attributed in NOTICE.