apache/rocketmq-spring: two parallel module families and one dependency that has no version

Two module families in one repository, and the README mentions neither

The top-level listing is where the story is. There are eight module directories and they form two identical families of four. The classic family is rocketmq-spring-boot-parent, rocketmq-spring-boot, rocketmq-spring-boot-starter and rocketmq-spring-boot-samples. The second family repeats the same four names prefixed for a version five client: rocketmq-v5-client-spring-boot-parent, rocketmq-v5-client-spring-boot, rocketmq-v5-client-spring-boot-starter and rocketmq-v5-client-spring-boot-samples. So a version five client integration exists in this repository alongside the original, built as a parallel set of parent, core, starter and samples modules rather than as a branch or a separate project. That is a deliberate structure and it has a consequence for anyone picking this up. The naming gives you no hint which family you need, and the README, which is the only place a newcomer is directed, documents exactly one dependency and does not mention the v5 line at all. A reader who assumes there is one integration here will configure the classic starter against a v5 broker and debug the mismatch. Before you write any configuration, establish which client your broker speaks and take the matching starter. The samples exist for both families, so the fastest way to resolve the question is to read the two sample directories side by side and see which one matches the deployment you have.

The dependency block has a placeholder where the version should be

Here is the entire usage section of this README, and it is a Maven dependency with the version left as a placeholder:

<!--add dependency in pom.xml-->
<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-spring-boot-starter</artifactId>
    <version>${RELEASE.VERSION}</version>
</dependency>

So the coordinates are clear, the version is not, and the placeholder is a Maven property the reader is expected to define. That is a common documentation convention and it is not wrong, but it means the README cannot be the source of your version. The release tags do not fill the gap either, because they are named after a different artefact. The recent releases are rocketmq-spring-all-2.3.6, rocketmq-spring-all-2.3.5 and rocketmq-spring-all-2.3.4, and the Maven Central badge in the header also points at an artefact in the same group called rocketmq-spring-all. The artefact you are told to depend on is called rocketmq-spring-boot-starter, and the artefact the release is named after is called rocketmq-spring-all. So there is an aggregator module in the published set that the README never mentions, and the version number in the tag belongs to it. The practical route is the obvious one and it is not written down anywhere: look the starter up in the artefact index and take the version that matches the release series you want. Anyone who copies the tag suffix and substitutes it into the starter coordinate is relying on a coincidence that happens to work and is not guaranteed to.

Fourteen checkboxes, and two of them are constraints

The feature list is a checklist of fourteen capabilities, and reading it as a list of checkmarks misses what two of the entries actually mean. The first is scheduled messages with delay level. The wording is specific: a delay level, not a timestamp. That means the delay you can request is selected from levels the broker defines rather than chosen as an arbitrary duration, so a requirement like deliver this in forty minutes has to be expressed as a level, and the resolution you get is the level granularity. That is a real design constraint, and it is the kind of thing that invalidates a schedule three days into an implementation. The second is filtering using the tag or an SQL 92 expression. Tag filtering is the common broker feature, but an expression language in the subscription is not universal, and it is worth knowing before you build a routing scheme on it. The rest of the list describes the modes that make up a message broker's surface, and two of them are about consumption shape rather than messaging style. Consuming with concurrent mode in either broadcasting or clustering covers the two distribution models, where broadcasting sends each message to every consumer and clustering shares them across the group. And push versus pull consumption covers who controls the read. The request-reply pattern is the outlier that is worth flagging: it gives you a synchronous call over an asynchronous broker, which is a genuinely useful tool and also the easiest way to build a system that falls over when the broker is slow. Use it deliberately, not by default.

Prerequisites say JDK 1.8 and Spring Boot 2.0, and say nothing about Spring Boot 3

The prerequisites are three lines: JDK 1.8 and above, Maven 3.0 and above, and Spring Boot 2.0 and above. Read them as a floor rather than a range, and the interesting question is what they imply. A library that declares a JDK 1.8 baseline is built for a generation of the framework that predates the namespace change in the Spring ecosystem, and the stated floor of Spring Boot 2.0 places it in the same generation. The upper end of the range is not addressed anywhere in the README, and there is no module in the listing that suggests a second generation of the integration. That matters practically, because Spring Boot 3 moved to a new namespace for its own APIs and to a Java 17 baseline, and an integration built against the earlier generation generally does not work across that boundary without changes. So the honest position is that the prerequisites tell you what this is known to work with, and they leave the current generation unaddressed. If you are on Spring Boot 3, this is a question to ask the project before you invest in it, not something to discover after wiring up listeners. The version picture is otherwise healthy, with three releases in the recent list, the newest from 2026-06-01, preceded by 2025-12-03 and 2025-06-23, and the last push on 2026-07-24.

Samples in the repository, documentation in a wiki, contribution notes on another site

The three places a newcomer is sent are all outside this README, and each is a different kind of resource. Samples come first, as a directory in the repository, one for each module family, so the examples are versioned with the code and cannot drift away from it. The user guide is the wiki on GitHub, which means it is a separate history from the code and describes whatever is current rather than what your version does. And the contribution documentation is on the RocketMQ main website, which is the umbrella project rather than this integration, so the process you are agreeing to is the broker's process, not this module's. That is a reasonable arrangement for a sub-project of a larger one, and it is worth knowing which of the three you are reading before you assume it describes the version you installed. Two smaller signals sit in the header. There is a coverage badge pointing at a service that aggregates coverage across repositories rather than storing it in the project's own tooling, and there are two badges that publish the project's own issue-handling metrics, one for the average time to resolve an issue and one for the percentage of issues still open. A project that displays its own resolution rate is making a statement about maintenance, and it is a more useful signal than a version number because it is measured continuously rather than claimed once.

A Travis badge over a repository with a GitHub directory, and what the version gap tells you

Two small inconsistencies, then the honest summary. The build badge in the README header points at a Travis endpoint rather than a GitHub Actions workflow, while the top-level listing contains a GitHub directory and the header also carries a GitHub release badge. Having a Travis badge in place next to a repository that has a GitHub presence is either a badge that was never updated or a build that genuinely still runs on that service, and either way it tells you the continuous integration story is not fully described in this repository. It is a small thing, and it is the kind of detail that tells you the README is maintained by hand rather than generated. The version picture deserves the last word, because it is the most useful signal in the project. Three releases appear in the recent list with roughly six-month gaps: 2.3.4 in June 2025, 2.3.5 in December 2025 and 2.3.6 in June 2026. The last push was on 2026-07-24, so the work continues and the newest release is not the newest commit. For a Spring Boot integration, that cadence is the right one, because the integration only has to move when Spring or the broker moves, and a six-month rhythm means you are not chasing a fast-moving dependency. So the project is in reasonable shape. What it lacks is not effort but orientation, since the two module families, the placeholder version and the unaddressed framework generation are all things a reader has to discover rather than read.

Editorial conclusion

Adopt this if you are on Spring Boot 2 with a RocketMQ broker and want the listener and template wiring handled for you, because the fourteen capabilities in the feature list cover the modes that otherwise dominate integration code, from ordered and transactional sends to broadcast and clustering consumers. Do not adopt it without checking two things the repository does not answer. First, there are two module families here, the classic one and the v5 client one, and the README documents only the classic starter, so confirm which line matches your broker before you write configuration. Second, the dependency block gives its version as a placeholder and the release tags are named after a different artifact, so the version has to come from the artefact index rather than from the tag. And if you are on Spring Boot 3, the stated prerequisites of JDK 1.8 and Spring Boot 2.0 do not address it, which is a question for the project rather than something to guess at.

Frequently asked questions

Official sources

1. apache/rocketmq-spring on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases