Getting Started

Begin with the smallest dependency and runtime that can complete one image task. Do not add every backend: Scrimage and libvips solve overlapping problems but have different deployment and ownership costs.

1. Import the central BOM

Choose the released bluetape4k-dependencies version used by the rest of the application.

dependencies {
    implementation(platform("io.github.bluetape4k:bluetape4k-dependencies:<version>"))
    implementation("io.github.bluetape4k.image:bluetape4k-images")
}

The repository also publishes bluetape4k-image-bom, but normal ecosystem consumers should use the central BOM so Kotlin, coroutines, framework, and sibling Bluetape libraries remain aligned. See the Image BOM reference when maintaining a narrower standalone dependency graph.

2. Pick one execution path

• Choose immutable image processing for portable JVM loading, writing, filters, transforms, and analysis.
• Add CAPTCHA, OCR, Ktor, or Spring Boot only when the application uses that capability.
• Choose Java 21 JVips when the service already runs JDK 21 and can install libvips.
• Choose Java 25 FFM when JDK 25 and native-access flags are acceptable.

Use Backend selection for a fuller comparison.

3. Run a workshop

The basic processing workshop is the shortest portable path. Framework applications can continue with the Ktor image API or Spring Boot image API. OCR has separate Ktor and Spring Boot workshops because host Tesseract setup is part of the exercise.

4. Verify the real boundary

Run the target module test, not only the root compile:

./gradlew :bluetape4k-images:test

Native and OCR checks require host software and must run sequentially. Read OCR setup and native resource lifecycle before enabling them.

Sources

• Release build configuration
• Release dependency examples