spring-boot-demo: 66 integration demos pinned to a 2018 Spring Boot

66 demos, 55 finished, and a TODO file as the request queue

The repository states its own numbers: 66 integration demos in total, 55 of them complete. It is written for deep study and hands-on practice with Spring Boot, and the README is the index, with a table mapping every module directory to a one line description of what it integrates.

The list is broad rather than deep. Actuator for monitoring, spring-boot-admin for a visual view of it, logback, AOP request logging, unified exception handling at both JSON and page level, four template engines in Freemarker, Thymeleaf, Beetl and Enjoy, then data access through JdbcTemplate, JPA, MyBatis, a generic Mapper, PageHelper, MyBatis-Plus and BeetlSQL, and the service side with upload to local disk and to Qiniu cloud, redis, ehcache, email, scheduled tasks, quartz, xxl-job, swagger, RBAC security, SpringSession, a Zookeeper lock built on AOP, RabbitMQ, Kafka, websocket, socket.io, UReport2, war packaging, Elasticsearch, Async, Dubbo, MongoDB, neo4j, docker, multi-datasource setups for both JPA and MyBatis, GrayLog, JustAuth, LDAP, dynamic datasource switching, Guava and Redis plus Lua rate limiting, Flyway and HTTPS.

The queue for what comes next is TODO.md, with an English TODO.en.md beside it. A demo that is not there yet is requested by opening an issue, and the maintainer adds it to that list.

master is on Spring Boot 2.1.0.RELEASE and the 1.5.x branch is frozen

The two branches differ in more than a version number, and the project says so plainly. The master branch is based on Spring Boot 2.1.0.RELEASE, and every module declares the root pom.xml as its parent, which is there to manage the dependency versions common to all modules and to make each demo easier to read on its own.

The v-1.5.x branch is based on Spring Boot 1.5.8.RELEASE, where each module instead depends on a shared spring-boot-demo-parent. The stated reason it is being closed is feedback from learners: that arrangement is not friendly to newcomers and is harder to run. So that branch will stop being developed and maintained, its content will be moved across to master piece by piece, and anything unfinished there will be added directly on master. Learners already on it are told they can continue, but are advised to move to master, on the grounds that Spring Boot itself has moved to 2.x.

That advice dates the material. The version this repository teaches is a 2018 baseline, so read the patterns rather than the version numbers, and check the current release notes yourself before copying a dependency choice into production.

The documented path runs through IDEA, not through a command line

The development environment is listed as four items, and the first three are a floor rather than a suggestion: JDK 1.8 or newer, Maven 3.5 or newer, and IntelliJ IDEA Ultimate 2018.2 or newer, with an explicit instruction to use IDEA for development and to make sure the lombok plugin is installed. The fourth is MySQL 5.7 or newer.

Then the run instructions, which are all IDE steps. Clone the repository:

git clone https://github.com/xkcoding/spring-boot-demo.git

Open the cloned project in IDEA, import the root pom.xml through the Maven Projects panel, and if that panel is not visible, tick View then Tool Buttons in the top toolbar so it appears on the right. After that, find the Application class of whichever module you want and run it.

The insistence on IDEA Ultimate is a real constraint rather than a preference in the text. Lombok is annotation based, so without the plugin the code will not compile in an editor that does not run the annotation processor, and no alternative command line recipe is given here. If your workflow is a terminal and a CI script, expect to supply that yourself.

MySQL 5.7+ with a note about not being backward compatible

The database requirement carries its own warning. MySQL 5.7 or newer is recommended, with the explanation that 5.7 added some new features and is not backward compatible. The project says the demos try to avoid that incompatibility where they can, but still recommends staying at 5.7 or above.

That is an unusually honest line for a demo repository, and it points at a real trap. A schema written against 5.7 syntax will fail outright on 5.6, and a driver or dialect choice that works on 5.7 may behave differently on 8. So the floor is not a formality: the data layer demos, which is most of the JPA, MyBatis, multi-datasource, Flyway and sharding modules, are the part of this repository most sensitive to the version you point them at.

Note also what the run instructions say about data. Some demos need database data initialised before they will do anything, and the README flags that as a separate step rather than folding it into the run. An empty schema is the most common reason a demo starts and returns nothing.

Every module is its own Application class, with its own README

There is no single entry point. Each module has an Application class, you run the one you are studying, and the README marks two things in bold: every demo ships a detailed README of its own that you are expected to read first, and some demos need database data prepared before they run.

Together those two warnings define the shape of the repository. It is a reference shelf, not an application. Cloning it and starting the build does not produce a running system, because there are fifty or so independent Spring Boot applications sharing one parent pom, and only the module you selected is ever wired to a database, a message broker or a template engine.

That is also what makes the parent pom arrangement worth understanding. Because every module inherits from the root pom, the shared dependency versions are decided once, and a module directory contains only what is specific to the demo you are reading. Swap the branch and that single point of version control changes with it, which is the difference the 1.5.x branch description is really about.

The directory listing has demos the prose list never mentions

The prose inventory describes what has been integrated. The directory listing is the ground truth, and the two are not identical. Among the module directories are demo-activiti for the Activiti workflow engine, demo-rbac-shiro for Shiro alongside the Spring Security module, demo-sharding-jdbc for sharding, demo-mq-rocketmq for RocketMQ alongside the RabbitMQ and Kafka modules, demo-pay for payments, and demo-swagger-beauty alongside the plain swagger module. None of those six appears in the list of integrated technologies in the README.

So the count and the table are a snapshot, and the filesystem is the current one. If you go looking for what the project can show you, search the directory names rather than the table, and expect the difference between the two to widen as demos are added.

The rest of the tree supports the teaching aim rather than a library. Both READMEs exist, README.md and README.en.md, as do both TODO files, and there is a .codacy.yml and a .travis.yml for the checks that run on every change. The MIT licence and the LICENSE file sit alongside them, and a jd.md file and a shortlist of related open source projects, including JustAuth, Mica, awesome-collector, SpringBlade and Pig, appear under the closing sections.

No releases, a last push on 2024-07-24, and a documented fork procedure

The repository has no GitHub releases, so there is nothing to download and no version to pin. What you consume is a branch, and the last push to it was 2024-07-24. Combined with the 2.1.0.RELEASE baseline, that dates both the code and the teaching material.

Forks get specific help, which says something about how the project expects to be used. The README carries a note for people who have forked it, pointing at a separate write-up on how to update a forked project, published on the author's own site. Taking a fork is a supported path, and the project gives you the procedure for keeping it in step rather than leaving you to merge by hand.

The contribution flow around it is equally informal. Bugs and pull requests go through GitHub, requests for new demos go through issues and land in TODO.md, and the repository also carries a .gitee directory, so the community is not confined to one host. If you are evaluating this for a team, the two things to weigh are that the patterns are still worth reading and that the dependency versions in them are from a Spring Boot generation that has since been overtaken.

Editorial conclusion

Use spring-boot-demo to read one working integration at a time, actuator with admin, MyBatis with PageHelper, Redis with a Lua rate limiter, Dubbo with the official starter, and to see how a Chinese team wires and annotates a Spring Boot service. Do not clone it expecting a project to build and run as a whole, since every demo is a separate Application class needing its own database data, and do not treat its dependency versions as current: master is on Spring Boot 2.1.0.RELEASE, IDEA 2018.2 and JDK 1.8, the v-1.5.x branch has stopped being developed, and the last push was 2024-07-24. Before you start, read the per-module README, decide which database demos you will initialise, and if you maintain a fork, follow the update procedure the project links rather than merging by hand.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository