Bluetape4k Projects Part 1: The Shared Kotlin/JVM Foundation

A shared foundation is quiet until it starts to shake.

2026-05-30 · bluetape4k-projects series · Part 1

This is Part 1 of the bluetape4k-projects series. The full series continues with Part 1: shared foundation, then Part 2: core, coroutines, logging, tests, Part 3: I/O, serialization, HTTP, encryption, Part 4: data and infrastructure, Part 5: utilities and adoption path, and Part 6: Spring Boot 4 and Ktor.

bluetape4k-projects is the broadest foundation in the bluetape4k ecosystem. It keeps the Kotlin/JVM utilities, coroutine helpers, I/O wrappers, data and infrastructure adapters, testing support, and BOM that backend services keep reaching for.

It is not a place where every feature stays forever. AWS, Exposed, Image, Text, Leader, and JaVers have moved into standalone repositories because they carry their own domain depth and release rhythm. projects keeps the shared foundation and runtime building blocks that many repositories and services depend on first. It is shared infrastructure: quiet when it works, suddenly interesting when it stops.

projects starts from the BOM and foundation, then supports runtime adapters and application code.

Why This Repository Exists

Kotlin/JVM backend work usually starts on proven Java libraries. The rough edges appear when those libraries meet Kotlin service code.

• Java APIs often do not fit Kotlin null-safety or DSL style.
• Callbacks, Future, and blocking APIs do not always compose cleanly with coroutines.
• Tests repeatedly need Redis, Kafka, databases, clocks, concurrency, and integration fixtures.
• Services re-create similar codec, serializer, timeout, retry, and logging conventions.

bluetape4k-projects reduces that repetition. The point is not to invent a new all-encompassing framework. It is a thin Kotlin-friendly layer over production libraries, smoothing the edges that services keep hitting.

implementation(platform("io.github.bluetape4k:bluetape4k-bom:<version>"))
implementation("io.github.bluetape4k:bluetape4k-core")
implementation("io.github.bluetape4k:bluetape4k-coroutines")
implementation("io.github.bluetape4k:bluetape4k-junit5")

The root README describes the same direction: idiomatic Kotlin helpers, Java library wrappers, coroutine integration, testing infrastructure, Redis/cache/infra support, and split repositories for domain areas large enough to need their own release rhythm.

Module Map

The current root README shows the boundary clearly.

The root README module map shows projects as both foundation and runtime adapter layer.

Area	Representative modules	Adoption trigger
Foundation	core, coroutines, logging, bom	Kotlin style, execution model, and dependency alignment
I/O	io, okio, csv, protobuf, jackson2/3, http, grpc	Bytes, files, serializers, HTTP, and RPC boundaries
Data	jdbc, r2dbc, hibernate, mongodb, cassandra	Persistence helpers and coroutine data access
Infrastructure	lettuce, redisson, kafka, nats, opentelemetry, resilience4j	Adapters around operational systems
Application	spring-boot/*, ktor/*, examples/*	Service entrypoints and working examples
Testing	assertions, junit5, testcontainers	Reusable integration-test fixtures

The model is selective adoption, not “pull in the whole ecosystem.” The BOM aligns versions, and each module can be picked up only when the service actually touches that boundary.

What Moves Out

As a feature area grows, keeping it inside projects can slow it down. One toolbox can hold a lot, but at some point it becomes moving day. bluetape4k splits those areas into standalone repositories.

Standalone repository	Why it moved out
bluetape4k-aws	AWS SDK v2 and Kotlin SDK service coverage has its own release cadence
bluetape4k-exposed	Exposed 1.2.x repositories, cache, and SQL DSL form their own ecosystem
bluetape4k-image	Pure JVM image processing and libvips/JNI/FFM need separate validation
bluetape4k-text	Korean/Japanese tokenizers and text search need their own dictionaries and quality bars
bluetape4k-leader	Leader election API and backend parity evolve as a focused subsystem
bluetape4k-javers	Audit/diff persistence spans Redis, Kafka, and Exposed on a separate release axis

The rough rule is simple: thin shared Kotlin/JVM foundation stays in projects; a domain with its own learning curve, release rhythm, and verification surface moves out. That keeps the foundation light and lets larger domains evolve at their own pace.

What the BOM Does

The BOM looks small, but it matters in a shared foundation repository. Kotlin, Spring Boot, Exposed, Jackson, Redis clients, and testing libraries all move at different speeds. Once versions start dancing independently, CI is usually the first one to get tired.

bluetape4k-bom aligns the module versions published from projects. Applications import the BOM first, then declare only the modules they need.

dependencies {
    implementation(platform("io.github.bluetape4k:bluetape4k-bom:<version>"))
    implementation("io.github.bluetape4k:bluetape4k-okio")
    implementation("io.github.bluetape4k:bluetape4k-r2dbc")
    testImplementation("io.github.bluetape4k:bluetape4k-testcontainers")
}

For Gradle Kotlin DSL, the root README recommends implementation(platform(...)) over dependencyManagement { imports } to avoid conflicts with KGP 2.3.x. The BOM is not a signal to use every module. It is a signal to keep the versions aligned for the modules you do use.

Where to Start

For a first pass through the repository, this order is usually the least noisy. Start with the map, then follow the problem your service is actually hitting.

1. Read the root README.md for the module map.
2. Skim core, coroutines, logging, junit5, and testcontainers.
3. Pick I/O, data, or infrastructure modules based on the boundary your service actually touches.
4. Use Spring Boot or Ktor examples to see application-level wiring.
5. Follow topic posts for cache, virtual threads, CSV/Okio, and benchmark-heavy areas when needed.

When a repository has many modules, first look at the shape, then pick the slice you need.

Source Links

• Repository: bluetape4k-projects
• README: README.md
• Korean README: README.ko.md
• BOM README: bluetape4k/bom/README.md
• Cache deep dive: Bluetape4k Cache Part 1

Closing

In one sentence, bluetape4k-projects is the shared foundation Kotlin/JVM backend services should not have to rebuild each time. Large domain capabilities move into focused repositories, while this repo keeps core utilities, coroutines, I/O, data, infrastructure, application support, testing, and the BOM aligned.

Next, we will open the innermost layer: core, coroutines, logging, and testing modules. The small foundations are not exciting until they are missing. Then they become the whole incident review.

Series Links

• Part 1: shared Kotlin/JVM foundation
• Part 2: core, coroutines, logging, tests
• Part 3: I/O, serialization, HTTP, encryption
• Part 4: data and infrastructure
• Part 5: utilities and adoption path
• Part 6: Spring Boot 4 and Ktor