spring-boot-all: A Spring Boot 1.5 Example Collection

What leehaut/spring-boot-all Solves

leehaut/spring-boot-all addresses the need to examine several Spring Boot integrations without combining them into one application. Its feature-specific directories include `spring-boot-mybatis`, `spring-boot-shiro`, `spring-boot-activemq-consumer`, `spring-boot-cache-redis`, `spring-boot-email`, `spring-boot-freemarker`, `spring-boot-websocket`, `spring-boot-quartz`, and `spring-boot-jpa-querydsl`. This structure is primarily useful to Java developers looking for a small reference point for persistence, messaging, caching, security, templates, or scheduled processing.

The repository is a collection of projects rather than a reusable Spring Boot starter. The README calls its directories Modules, while the repository layout includes separate parent, sample, and integration directories. It does not describe one deployable application containing every listed feature. A reader should therefore choose a directory according to the subject being studied instead of expecting every directory to participate in a single runtime flow.

The scope is broad but uneven. Some subjects have paired examples, such as ActiveMQ producer and consumer modules or Redis and Ehcache cache modules. Others, including email, Quartz, SiteMesh, and Springfox, occupy individual directories. This makes the collection convenient for code inspection. It does not explain how these examples are intended to work together, and it offers no documented compatibility policy between them.

The spring-boot-parent Build Boundary

The documented build relationship is centered on `spring-boot-parent`. According to the README, all Modules depend on that shared parent. Its XML shows `org.springframework.boot:spring-boot-starter-parent` at version `1.5.19.RELEASE`, followed by a list of sibling modules and a separate `spring-boot-hello` project.

The shared parent creates a clear versioning boundary. A change there could affect every selected example, so engineers copying code should inspect the parent rather than examining only one feature directory. The feature list is also selective. Top-level entries include `spring-boot-hibernate5`, `spring-boot-samples`, `spring-boot-sharding`, and `spring-boot-websocket-netty-server`, but those names do not all appear in the displayed module list. Inclusion in a Git repository directory does not confirm that a project is included in a multi-module build.

The README links to the Spring Boot 1.5 reference documentation, but it does not identify a root build file, wrapper, build profile, or command that assembles the whole repository. It also does not document Java and Maven prerequisites. The architecture is visible as a parent project plus selected child modules, yet its exact build entry point remains undocumented in the README.

Installing and Preparing a First Example

The README does not document repository-specific installation, build, or run commands. It says to depend on version `1.5.19` and links to the Spring Boot 1.5 reference documentation. It does not provide Java and Maven version requirements, a wrapper command, expected application output, or instructions for starting Redis, ActiveMQ, a database, or a mail server. The following is the parent declaration reproduced by the README, not a complete installation procedure:

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>1.5.19.RELEASE</version>
</parent>

This block establishes the documented Spring Boot parent version. A reader should not expect it alone to start any application. To prepare a first real use, select one feature directory, inspect its parent and dependency declarations, then locate its application configuration and runnable class. The README does not identify those internal files, so a command such as `mvn spring-boot:run` would go beyond its documented instructions.

The visible examples also differ in external requirements. ActiveMQ examples involve producer and consumer projects, Redis examples may require a Redis service, and persistence examples may need database configuration. Their exact environment variables, connection strings, and ports are not documented in the README. The first-use verification therefore has to happen at module level, using its own files rather than relying on a repository-wide command.

Persistence Modules and Their Separate Boundaries

The repository uses distinct directories for competing and complementary persistence approaches. `spring-boot-mybatis` represents MyBatis, while `spring-boot-jpa` and `spring-boot-jpa-querydsl` cover JPA and QueryDSL examples. `spring-boot-hibernate5` is listed as a top-level directory, and `spring-boot-sharding` represents database sharding. The naming shows that the repository does not treat persistence as a single fixed stack.

This separation gives readers several subjects to compare without loading every persistence library into one project. It also avoids implying that MyBatis, JPA, Hibernate, and QueryDSL are configured together by default. The README lists a starter for JPA, Spring ORM, and Hibernate, but it does not provide a module-by-module dependency matrix. It also does not document schemas, migrations, connection settings, transactions, or example records.

The distinction matters for adoption. A developer looking for a MyBatis configuration example has a clear directory in which to begin. A developer evaluating JPA has different directories to inspect. Someone needing a single production-ready persistence configuration gets no guidance about which combination is recommended. The repository is better treated as a set of study examples than as a prescribed persistence architecture.

ActiveMQ, Redis, and Ehcache Example Separation

Message handling is divided between `spring-boot-activemq-producer` and `spring-boot-activemq-consumer`. That directory split identifies the sending and receiving sides of an ActiveMQ example without implying a shared broker configuration. The README does not document queue names, serialization, acknowledgements, retry policies, redelivery behavior, or failure handling. It would be incorrect to infer delivery guarantees from the producer and consumer labels alone.

Caching is similarly divided into `spring-boot-cache-ehcache` and `spring-boot-cache-redis`. Both topics connect with the starter reference in the README, which identifies `spring-boot-starter-cache` as support for Spring's Cache abstraction and `spring-boot-starter-redis` as Redis support through `spring-redis`. However, the README does not explicitly say that the two modules use one identical application interface or compare their behavior.

This structure favors focused inspection. A developer can examine a broker integration or a cache backend without navigating a single giant sample. The cost is missing comparative context. The documentation does not state whether cache entries are shared across instances, how expiration is configured, how failures are surfaced, or which module should be used for a given workload. Those details must be checked in the individual projects.

Security, WebSockets, and UI-Facing Examples

Security appears in `spring-boot-shiro` and `spring-boot-shiro-redis`. The separate Redis-backed directory suggests a distinct example that connects Shiro with Redis, although the README does not define the sessions, permissions, realm, or cache behavior implemented there. Developers should not assume that either directory demonstrates a complete production security model because no authentication flow or threat model is documented.

WebSockets are represented by `spring-boot-websocket`, `spring-boot-websocket-client`, and `spring-boot-websocket-netty-server`. This gives the collection separate client, standard WebSocket, and Netty server areas. The README's starter table identifies `spring-boot-starter-websocket` as support for WebSocket development, but it does not explain message formats, endpoints, broker configuration, reconnection behavior, or whether the Netty project is the server implementation used by the other examples.

The UI-facing modules include `spring-boot-freemarker`, `spring-boot-sitemesh`, `spring-boot-easyui-kindeditor`, and `spring-boot-welcome-page`. They cover templates, layout decoration, an editor-oriented example, and welcome-page configuration as separate concerns. Again, the README provides inventory rather than application flow. Routes, templates, static assets, security rules, and expected browser behavior are not documented there.

Springfox, Quartz, and Operational Gaps

`spring-boot-springfox` is the directory associated with the repository's `springfox` and `swagger` terms. The README's starter table does not explain how the module is configured, which endpoints it exposes, or whether it includes a browser interface. There is no documented Swagger configuration or generated API example to reproduce from the README. The directory establishes that API documentation tooling is represented, but not that every other module is documented with it.

`spring-boot-quartz` similarly identifies scheduled-job support as an example topic. The repository description names Quartz, while the directory list confirms the dedicated module. The README does not document job definitions, triggers, persistence settings, clustering, failure recovery, or an Actuator view. Those are central operational concerns when Quartz is used in production, and their absence makes this a learning example rather than a deployment guide.

The repository also includes crawler, Activiti, devtools, and samples directories. The README does not explain their entry points or integration relationships. Likewise, its starter reference describes production monitoring through `spring-boot-starter-actuator`, but it does not say which project configures Actuator or which endpoints are exposed. Engineers evaluating operations should not equate the presence of an Actuator starter description with a documented monitoring configuration.

Maintenance Scope and Apache-2.0 Implications

The repository is not archived, and its last push was on 2026-08-17. It has no GitHub releases. There is therefore no release entry documented through GitHub Releases, while the parent remains explicitly tied to `1.5.19.RELEASE`. The README does not provide migration notes or a compatibility matrix for later Spring Boot versions.

The shared parent increases the potential upgrade cost for copied projects. Changes to dependency management can affect several directories at once, and individual modules may also contain assumptions tied to the stated Spring Boot line. Engineers should account for reviewing the parent, each selected child, its external services, and its configuration when changing framework versions. The repository layout gives clear locations for that review, but the README does not state that the examples are compatible with any newer release.

The repository identifies Apache-2.0 as its license. That supplies the stated licensing framework for reuse and distribution, including its license and notice conditions. Teams copying code into an application should inspect the repository's `LICENSE` file and preserve applicable notices. This is a project-specific compliance step, not legal advice.

Choosing Between Examples and a Single Application

A real alternative is to create one application with only the Spring Boot starters required for its actual requirements. The README lists focused starters including `spring-boot-starter-web`, `spring-boot-starter-data-jpa`, `spring-boot-starter-redis`, `spring-boot-starter-mail`, `spring-boot-starter-actuator`, `spring-boot-starter-test`, and `spring-boot-starter-websocket`. Unlike spring-boot-all, this approach does not carry a collection of unrelated example directories through the build.

The alternative changes the decision model. spring-boot-all helps a developer compare isolated implementations for MyBatis, JPA, Shiro, Redis, Ehcache, and ActiveMQ. A single application instead gives each dependency a declared runtime purpose. It avoids inheriting the example collection's `1.5.19.RELEASE` parent unless that version is deliberately selected. The README does not supply such an alternative configuration, so it cannot be presented as a repository-specific command.

For a current service with explicit infrastructure requirements, a purpose-built application is the cleaner starting point. For historical study of how older Spring Boot integrations were separated into projects, spring-boot-all has more direct value. Its boundary is clear: it offers directories to inspect, but no documented setup, endpoint contract, compatibility statement, or release series for adopting the collection unchanged.

Editorial conclusion

Developers studying how Spring Boot 1.5 integrations can be separated into example projects may use individual directories as references. Teams starting a new service should not treat the collection as an application foundation. Verify first whether the `1.5.19.RELEASE` parent, selective module list, absent setup instructions, and lack of GitHub releases match their build and upgrade requirements.

Frequently asked questions

Official sources

1. Issues
2. leehaut/spring-boot-all on GitHub
3. License: Apache-2.0
4. README