# skrstop-components: a Spring Boot component library with a wide starter set

> skrstop-components is a Java component library for Spring Boot that bundles the parts most services end up writing anyway, a unified response wrapper, a common exception model, and auto configured starters for the database, Redis, MongoDB, object storage and more, with the library versions pinned so a project gets a tested combination. It suits a team that wants the plumbing assembled for it, and it asks for JDK 17 and a large dependency surface.

**skrstop/skrstop-components** — 基于springboot的常用功能封装，包括：通用响应、通用异常、数据库、redis、远程存储、常用自定义注解、多数据源等，省去各种配置和通用配置，开箱即用，支持jdk8+、jdk17+

- Repository: https://github.com/skrstop/skrstop-components
- Stars: 1,098 · Forks: 48
- Language: Java
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/skrstop-skrstop-components

## What the project is

skrstop-components is a set of Spring Boot components covering the functionality that most services need: a unified response format, common exception handling, the database, Redis, remote object storage, frequently used custom annotations and multiple data sources, with the point of the project being to remove all the repetitive configuration and make the result work out of the box. The repository description also states support for JDK 8 and later and JDK 17 and later, and the minimum version section at the top of the README narrows that to the current reality, JDK 17, with the note that below JDK 17 you should use the 1.2.x version.

That is an unusual but sensible arrangement for a component library, because it lets a library keep one current line for modern Java while continuing to serve teams that cannot move yet. It also means the two lines do not share features, so a team on the older branch is on its own.

The project is Apache-2.0 licensed and published to Maven Central under the group identifier com.skrstop.framework, with the artifact identifier following a components-xxxx-xxxxxxxx pattern, so each module is published separately and you depend only on what you use.

```xml
<dependency>
    <groupId>com.skrstop.framework</groupId>
    <artifactId>components-xxxx-xxxxxxxx</artifactId>
    <version>${skrstop.version}</version>
</dependency>
```

The README says the artifacts are uploaded and to use them as needed, which is the right approach for a modular library. The last push to the repository was on 2026-10-13, and the recent releases are the 3.3.1 and 2.7.1 lines from May 2026 published in October, with the 1.3.2 line from May 2024.

## The module layout, and what each group is for

The README prints the whole module tree as an ASCII diagram, and reading it is the fastest way to understand the project.

The core group holds the foundation. There is a core common module for base entities and interfaces, a core exception module for the common exception types and the exception interface, and a core annotation module for the shared custom annotations.

The starters group is where the auto configuration lives, and it is the largest part of the tree. There is a common starter, a starter for the shared annotations, one for the banner, one for the database, one for Feign with HTTP2 and protobuf support, one for the id service, one for extra metrics, one for MongoDB, one for object storage, one for automatic port shifting, one for Redis with encapsulated helper methods, one for general Spring support methods, and the web starter, which is the one that provides the unified return value and the exception handling.

The utils group is a set of standalone helper modules with no Spring dependency in the description. There is compression, a constants pool, encryption and decryption, database helpers, an in-process event model, a thread pool, a grab bag of extras covering emoji, FTP, QR codes, email and image captchas, an HTTP client with a JDK and an OkHttp implementation, media processing for video, images and file recognition, serialisation for json, gson and protostuff, property file handling, a local stress testing package, system helpers for IP and port detection, running scripts and reading system parameters, and a value module for beans, strings, arrays, collections, numbers, dates, objects, lambdas, reflection, streams and assertions.

There is also an examples group, with a Feign based cloud example and a simpler starter example, and a project group that holds the parent pom for business projects.

The structure is the argument for the library. Everything a service usually reimplements is a named module you can depend on individually.

## The starters, and the promise of zero configuration

The starters are the part of the library that changes how a service is built, and the mechanism is the standard Spring Boot auto configuration model with a module per concern.

The web starter is the one with the widest effect, because it delivers the unified return value and the exception handling. In a Spring Boot service, the shape of a controller response and the shape of an error response are the two decisions every project makes and then rewrites, and a starter that sets both means the convention arrives with the dependency instead of being copied from a template.

The database starter covers the persistence setup, the Redis starter covers the cache and lock helpers, the MongoDB starter the document store, and the object storage starter the remote file storage. The feign starter adds HTTP2 and protobuf support to the declarative client, and the metrics starter adds extra monitoring metrics.

Two of them are worth singling out because they solve problems that are otherwise solved by scripts. The port shift starter shifts the ports automatically, which is the thing that lets several of your own services run on one machine, or several of your own test environments run on one host, without hand editing configuration. And the id starter covers the id service, which is the identifier generation piece that tends to be a small dependency in one team and a shared platform in another.

The extras module is separate from the starters, which is the right boundary. The extras are optional and mostly independent, while the starters are the parts you want turned on by default in a service.

## The pinned versions, and what that means for upgrades

The README lists the library versions the project is built and tested against, and that list is the most consequential part of the documentation for an adopter.

```
springBoot 3.3.13
springCloud 2023.0.6
springCloudAlibaba 2023.0.3.4
log4j 2.24.3
lombok 1.8.42
mybatis 3.5.19
mybatis-plus 3.5.7
redisson 3.43.0
druid 1.2.24
hutool 5.8.41
fastjson 2.0.59
morphia 2.5.0
```

Two observations. The first is that the versions are mutually consistent, which is the value of a curated set. Spring Boot, Spring Cloud and Spring Cloud Alibaba in particular have to line up, and getting a compatible triple right by hand is a known chore.

The second is that this is a broad surface. The list spans the application framework, the cloud stack, two logging and utility libraries, two ORM choices, the Redis client, the connection pool, a JSON library, a fast JSON library and a MongoDB object mapper. A service that takes several of these starters inherits all of them, and inherits their upgrade schedule.

That is the trade of a curated component library in one line, and it is a trade rather than a defect. A team that would otherwise pin these itself gets a tested combination and a maintainer who does the work, at the price of following the library's cadence rather than setting its own.

The plan for the future is short and concrete, with Alibaba Cloud OSS and Huawei Cloud OBS to be added to the object storage starter, and a starter for MQTT.

## The version scheme, and the two lines

The release names are unusual and they encode something useful.

The three most recent releases are named 3.3.1.20260520-RELEASE, 2.7.1.20260520-RELEASE and 1.3.2.20240510-RELEASE. The pattern is a component line version, then a build date, then the release marker. The two releases from 2026 share the same build date, which tells you they were produced from the same source tree on the same day and differ in which component line they belong to.

That is what a component library with several supported lines looks like in practice. The major version of the release is the line, and the date is the build, so a service on the 2.7.1 line and a service on the 3.3.1 line can be on the same patch level.

The 1.3.2 line is from May 2024 and is the one that serves teams below JDK 17, so a project on the older line is also two years behind on the dependency versions, which is the real cost of staying there.

The repository layout is a plain multi-module Maven build, with the module directories, the parent pom at the root, a changelog and the licence file, plus an agentbridge directory that looks like tooling for an agent workflow. There is a changelog at the root as well, so the history is in the repository rather than only in the release tags.

## The alternative, and who should read this

The honest alternative to this library is assembling the same starters yourself, which for most teams is what they did before.

Spring Boot already ships starters for the database, for MongoDB and for a web layer, and Spring Cloud ships the service discovery, configuration and gateway pieces. The Redis, object storage and feign additions come from other projects. Putting them together is a day of work for somebody who knows the compatibility matrix, and then it is that person's job to keep it working as the frameworks move.

The difference this library offers is that the choices are made, pinned and tested together, and the response and exception conventions come with the web starter rather than being copied between services. The cost is the dependency surface and the cadence.

So the question is whether your organisation is the kind that keeps a curated component library or the kind that curates its own dependencies per service. A company with several services and a platform team gets real value from this, because the platform team can change one version and the convention travels with it. A single service with a strict dependency policy probably does not.

One more detail is worth noting for readers outside China, because the project is hosted with a mirror that is intended for it. The acknowledgements thank AtomGit for hosting the project domestically so that users there can reach it and download releases faster, and the README links the Chinese social channels, the Bilibili account, the funding page and the translation platform where the community work happens.

The project is a good example of a component library that has grown by accumulating the things a team kept writing, and the directory tree is an honest record of what that accumulation looks like.

## Conclusion

Adopt skrstop-components if your team keeps writing the same response wrapper, exception handling and infrastructure glue for every Spring Boot service, because those parts are exactly what the starters and core modules cover. Do not adopt it in a service with a strict dependency policy, since the library pins a large set of versions for you, including frameworks, an ORM and several serialisation libraries, and those pins become your upgrade schedule. Before you depend on it, check the JDK floor, since the current line needs JDK 17 and older JDKs are only served by the 1.2.x branch.

## FAQ

### What is skrstop-components?

It is a Spring Boot component library for Java that bundles the pieces most services end up writing themselves, a unified response wrapper, common exception handling, the database, Redis, remote object storage, shared custom annotations and multiple data source support, with the intent of removing the repetitive configuration and working out of the box.

### What Java version does skrstop-components require?

The current line requires JDK 17. The README says that below JDK 17 you should use the 1.2.x version, so the older line is still published but is two years behind on the bundled library versions, which include Spring Boot 3.3.13, Spring Cloud 2023.0.6 and MyBatis Plus 3.5.7.

### How do I add skrstop-components to a Maven project?

The artifacts are published to Maven Central under the group identifier com.skrstop.framework, and you depend on the specific module you need, using the components-xxxx-xxxxxxxx artifact naming with your own version property. The README says to use them as needed rather than pulling the whole set.

### What do the starters in skrstop-components do?

Each starter is an auto configuration module, and the set covers the database, Redis with encapsulated helper methods, MongoDB, object storage, the id service, Feign with HTTP2 and protobuf support, extra metrics, the banner, shared annotations, general Spring support, automatic port shifting, and the web starter that provides the unified return value and the exception handling.

## Sources

- [Issues](https://github.com/skrstop/skrstop-components/issues)
- [License: Apache-2.0](https://github.com/skrstop/skrstop-components/blob/main/LICENSE)
- [README](https://github.com/skrstop/skrstop-components/blob/main/README.md)
- [Releases](https://github.com/skrstop/skrstop-components/releases)
- [skrstop/skrstop-components on GitHub](https://github.com/skrstop/skrstop-components)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/skrstop-skrstop-components