SpringBootUnity is thirty Spring Boot examples, one module each

The project says it is a collection, not a product

The project description is a list of technologies: RabbitMQ, Redis, scheduled tasks, sockets, MongoDB, Swagger2, Spring Data JPA, Thymeleaf, FreeMarker and more, described as a multi module Spring Boot project with different business scenarios using different technologies.

The README is explicit about what that means. Requirements are changeable, so the project is based on Spring Boot and pairs different technologies with the framework according to different needs, making each combination a separate module, which means it is a collection of usage examples rather than a complete product. Each module can be packaged and started independently without affecting the others, so you can pick only the one you care about and run it. The README also invites pull requests for useful technology combinations found while working with Spring Boot.

That framing is the most important thing for an evaluator, because it tells you what you are looking at. This is not a framework, not a starter, and not something to fork into production. It is thirty worked examples in one repository, each small enough to read in an afternoon.

The licence is MIT, the primary language is Java, the default branch is main, and the homepage is houko.github.io/SpringBootUnity. The last push was on 2026-09-14, and the repository publishes no GitHub releases, so the changelog file is the version history.

One detail from the project status section is worth carrying into any decision. The project is positioned as an example collection, modules are added or removed as needed, and feedback goes through the issue tracker, which is also where you ask for a technology combination you would like to see.

The module table is the real documentation

There are 30 modules, and the README presents them in a table with the demonstrated content, the start class and the external services each one needs. That table is the most useful page in the repository.

The core module is the shared foundation, holding utility classes, base classes, constants, exceptions and filters. It is depended on by all the other modules and explicitly cannot be run on its own. Everything else demonstrates one technology.

The interesting ones are worth naming. The website module is a personal site with JPA, FreeMarker pages and OpenAPI endpoints, described as the most complete module in the project, and it needs MySQL and Redis. The javase module is a question bank API, a typical CRUD over JPA with OpenAPI. The order module is an order API with zxing QR code generation and needs nothing external. The crawler module is a jsoup scraper that stores what it fetches and needs MySQL. The socket module is a WebSocket chat application and it uses port 8081, while everything else listens on 8080, which is why you start one module at a time.

Then there is a long tail of single technology modules: mybatis, multipleSource for multiple data sources and switching, redis, rabbitmq, security with Spring Security form login, scheduled, async, freemarker, thymeleaf, validation, fileupload, restclient, cache, actuator, aop, httpinterface, i18n, ratelimit, graphql, kafka, mail, elasticsearch and flyway.

The whole table is browsable in one screen, which means you can find the exact combination you need without reading any code, and then read the one module that matters.

One module at a time, on port 8080

The quick start section is four commands, and the design decision behind them is that each module is a separate application.

Building everything is:

mvn clean install

Starting one module, for example the order module which depends on no external service, is a plain Java invocation of the packaged jar:

java -jar order/target/order-2020.1.jar

Or you can let Maven run it, targeting the module directly:

mvn spring-boot:run -pl order

And in an IDE you find the module's Main class and run it. The README is explicit that since every module except socket listens on port 8080, you start only one at a time.

The deployment example shows what a server run looks like, with the heap flags and the output redirected to a log file:

java -Xms64m -Xmx2048m -jar order-2020.1.jar >> ./order.log 2>&1 &

The README notes that Spring Boot has Tomcat built in, so for a server deployment you copy the built jar up and run it.

For the modules that expose OpenAPI annotations, which the README lists as website, javase, order and mongodb, there is a Swagger UI at localhost:8080/swagger-ui.html and the OpenAPI description at localhost:8080/v3/api-docs.

And if you need to deploy to an external Tomcat, the packaging is changed in the module's pom.xml:

<packaging>war</packaging>

Fourteen modules have tests you can run without any service

The paragraph about tests is the strongest argument for using this repository, and it is easy to miss in a README this long.

Fourteen modules ship directly runnable tests: validation, fileupload, restclient, cache, actuator, async, aop, httpinterface, i18n, ratelimit, graphql, kafka, mail and flyway. None of their tests depend on an external service. The kafka module uses an embedded Kafka, the mail module uses an embedded SMTP server through GreenMail, the flyway module uses an embedded H2, and the rest use a Spring test context. The README says mvn test runs them all, and that they can be read as executable documentation for each technology point.

That is a meaningful difference from a repository of snippets. A snippet shows you the shape of a thing. A module with a test that runs in a few seconds shows you the shape and the behaviour, and it does it in a way that a reader can verify on their own machine without a broker, a database server or a mail server.

The test command is the plain one:

mvn test

For the modules that do need external services, the table at the top of the README says which ones: MySQL and Redis for website, MySQL for javase, mybatis and crawler, MySQL twice for multipleSource, Redis, RabbitMQ, MongoDB, Kafka, an SMTP server and Elasticsearch. The environment requirements section makes the same point, saying that you prepare the external services for the modules you need and that running only the modules without external services requires no preparation at all.

So the practical path into this repository is to find the one module that matches your problem, run its module alone, and read it.

Configuration lives in each module, and the credentials are placeholders

The configuration section is short and it contains a warning worth reading before anything else.

Each module's configuration is in its own src/main/resources/config/application.properties, with the logging configuration in logback-dev.xml in the same directory. So there is no single application.properties for the whole project, which follows from the modules being independent applications.

For the modules that touch a database, the README says to change the connection information in the spring.datasource.* properties first. Most of them use Hibernate's ddl-auto=update, so when no SQL files are provided the tables are created from the entity class mappings. That is convenient for a sample and wrong for production, because it means the schema is whatever the entities happen to say rather than something you reviewed.

And then the warning: the account names and passwords in the repository are all placeholders, and you should not commit real credentials into the repository. The same applies to the third party login keys in core/src/main/resources/config/oauth.properties, where you should either fill in values you applied for yourself or inject them from environment variables.

That instruction is the difference between a sample repository and a careless one, and it is worth noting that it exists at all. The rest of the configuration is ordinary Spring Boot configuration for the technology the module demonstrates, and the logs are configured per module rather than globally.

A recent migration to Spring Boot 4, and a licence that changed once

The changelog section tells a story of a project that has been upgraded repeatedly, and the recent entry is a large one.

On 2026-09-09 the project moved to Spring Boot 4.1.1 and JDK 21, with all dependencies updated to their latest versions. The javax.* namespace was migrated to jakarta.*, the API documentation moved from the unmaintained springfox to springdoc-openapi, the security module switched to component style configuration with SecurityFilterChain, fastjson was migrated to fastjson2, Jackson was upgraded to 3.x, POI to 5.x, and a GitHub Actions build CI was added.

The earlier entries show the same pattern at smaller scale: Spring Boot 2.3.0 and JDK 11 in October 2020, a Spring Boot 2.0 release with significant API changes in April 2018, the api and website modules merged in November 2017, and a licence change from Apache to MIT on 2017-11-02.

The technology table gives the current state. Spring Boot 4.1.1, JDK 21 as the compile target with CI building on both 21 and 25, Maven 3.9 or newer, Hibernate and Spring Data JPA 7.x, Jackson 3.x, springdoc-openapi 3.x for OpenAPI 3.1, and the MySQL Connector/J driver. The environment requirements say JDK 21 or higher, noting that the minimum for Spring Boot 4 is 17, and Maven 3.9 or higher. The README also notes that versions for Spring, Jackson, Hibernate and JUnit are managed centrally by the spring-boot-dependencies BOM and are not pinned in this project.

The build status and CodeQL badges in the README reflect that CI, and the project is also hosted on Gitee with GitHub taken as the authoritative copy.

Editorial conclusion

Adopt SpringBootUnity if you are learning Spring Boot or need a reference implementation for one specific integration such as Kafka, GraphQL, Flyway, Elasticsearch, RabbitMQ or a rate limiting interceptor, and you are happy to work from a sample rather than a library. Do not adopt it as a production application skeleton, because the project states plainly that it is positioned as a collection of examples with modules to be added or removed as needed, and do not expect a shared abstraction layer, since each module demonstrates its own technology. Before you start, pick the one module you need, read its Main class, change the datasource settings and the placeholder credentials, and run mvn test, because the fourteen modules with self contained tests are the part you can trust without provisioning a database or a broker.

Frequently asked questions

Official sources

1. houko/SpringBootUnity on GitHub
2. License: MIT
3. Project website
4. README
5. Releases