Spring AMQP: the Spring programming model on top of RabbitMQ

What the project actually provides

Spring AMQP is the Spring project's support layer for AMQP 0.9.1. The README states it provides support for using Spring and Java with AMQP 0.9.1, and in particular RabbitMQ.

That scope statement is more informative than it looks. AMQP 0.9.1 is the protocol RabbitMQ speaks, and it is not AMQP 1.0, the protocol standard that other brokers such as Qpid and ActiveMQ Artemis implement. A project that says it is AMQP 0.9.1 is talking about the older protocol with its exchange, queue and routing key model, and about a wire format that many tools understand.

The value of the project is that this protocol layer is expressed in the Spring programming model. Instead of a raw channel and a hand written consumer loop, the pieces arrive as Spring beans, with configuration handled the way the rest of a Spring application expects, and with the integration points that the surrounding framework provides.

The README itself is not a feature document. It covers the code of conduct, the security vulnerability reporting policy, how to check out and build the project, how to import it into an IDE, the changelog location, the additional resources and the contribution and code conventions. That tells you what kind of project this is: an infrastructure component of the Spring ecosystem, maintained under the Spring contribution rules, where usage documentation lives on the project homepage rather than in the repository readme.

Nine modules and what each one is for

The top level of the repository lists the modules, and they explain more about the design than the README does.

There is spring-amqp, which is the generic layer: the abstractions that do not care whether the broker is RabbitMQ. Next to it sits spring-amqp-client, the low level client support, and spring-rabbit, the RabbitMQ specific implementation that binds to the broker. spring-rabbitmq-client is a separate artifact that carries the RabbitMQ Java client itself, which is how the project keeps a dependency that many teams would otherwise pull in directly.

The testing modules are the other interesting group. spring-rabbit-test and spring-rabbit-junit exist so that a test can exercise code that talks to a broker without a broker in the loop. There is also spring-rabbit-stream, which covers the RabbitMQ streaming protocol as a separate surface from the queue based one.

And spring-amqp-bom is a bill of materials module, so a project can align the versions of the whole family with one entry.

The src directory at the root holds the documentation sources, and the presence of a separate src/eclipse directory, referenced in the code conventions, suggests the project keeps its Eclipse formatting configuration in the tree. build.gradle, settings.gradle, gradle.properties, the gradle wrapper and publish-maven.gradle make up the build, and commercial-settings.gradle points at the build configuration used for the commercial Spring offerings.

Building the project with the Gradle wrapper

The build instructions in the README are short, and they assume the Gradle wrapper that ships in the repository.

	git clone git://github.com/SpringSource/spring-amqp.git
	cd spring-amqp
	./gradlew build

The wrapper means you do not need a matching Gradle installation on the machine. The clone URL in the README points at the SpringSource mirror, which is the historical location for Spring projects.

If the build runs out of memory, the README has a specific remedy: increase the heap and permgen available to Gradle.

	GRADLE_OPTS='-XX:MaxPermSize=1024m -Xmx1024m'

That setting is old fashioned, since modern JVMs no longer use permgen, and the README predates the current JDK baseline. Treat it as historical advice rather than as something to paste into a current environment.

The rest of the build tasks are equally conventional. Publishing the jars into your local Maven repository is one task:

	./gradlew publishToMavenLocal

And the documentation is built separately, with the api task producing Javadoc into build/api and the antora task producing the reference documentation into build/site. The dist task assembles the complete distribution, including the dist, docs and schema zip files into build/distributions, and the README notes that this one expects Sonar to be running, for example on localhost port 9000.

Importing the build into Eclipse, STS and IntelliJ

Three IDE paths are documented, and they differ in how much work they ask of you.

For Eclipse, the README runs the eclipse task to generate the .classpath and .project files, and then tells you to import them through File, Import, Existing projects into workspace, browsing to the spring-amqp root directory. It expects the import to complete without errors.

For Spring Tools, the STS Gradle support imports Gradle projects directly, without generating Eclipse metadata first. The README gives the menu path, File, Import, Existing Gradle Project, then browsing to the Spring AMQP root folder and clicking Finish.

For IntelliJ IDEA, the README generates IDEA metadata with the .iml and .ipr files:

    ./gradlew idea

The fact that all three are supported says something about the audience. Contributors to a Spring project are expected to work in whatever IDE they prefer, and the build system is kept IDE agnostic on purpose, with the IDE specific files generated on demand rather than committed to the tree.

For anyone who only wants to use the library rather than work on it, none of this applies. The published artifacts are consumed through Maven or Gradle like any other Spring module, and the build section is relevant only to people changing the code.

Contributing under the DCO rather than a CLA

The contribution rules have changed recently, and the README spells the change out.

All commits must include a Signed-off-by trailer, indicating that the contributor agrees to the Developer Certificate of Origin. The README links a Spring blog post titled Hello DCO, Goodbye CLA, which announces the switch away from a contributor licence agreement.

The README is careful about what that does and does not mean. The DCO does not grant anyone commit rights to the main repository, but it means contributions can be accepted, and the author gets credit if they are. Active contributors might be asked to join the core team and given the ability to merge pull requests.

Beyond the legal sign off, the code conventions section lists the house style that reviewers will expect. Use the Spring Framework code format conventions from src/eclipse if you are working in Eclipse. New .java files need a simple Javadoc class comment with at least an @author tag and, preferably, a paragraph on what the class is for. Every new file needs the ASF license header comment, copied from existing files in the project. Substantially modified files should list you as an @author. Javadoc is expected, and if you change a namespace then the XSD doc elements need updating too. Unit tests would help, as the README puts it, someone has to write them. And a branch nobody else is using should be rebased against the current main.

Releases, milestones and the changelog

The release tags show how the project is versioning itself at the moment: v4.2.0-M2 on 2026-09-24, v4.2.0-M1 on 2026-08-20, and v4.1.1 on 2026-08-20.

The M suffixes are milestone releases. A 4.2.0 milestone is a pre-release of 4.2.0, and the M1 and M2 tags are the first two steps of that sequence. Two things follow for an adopter. First, milestone artifacts are snapshots of work in progress, and whether they land in a public repository depends on the project's publishing policy, so a production build should stay on a release tag or on the version your Spring Boot dependency management selects. Second, the 4.2 line is not finished, which is why the 4.1.1 maintenance release and the 4.2.0-M1 milestone share a date: the team shipped a fix on the stable line and moved on in parallel.

The last push to the repository was on 2026-10-16, so the branch is being worked on actively.

For what changed, the README points at the GitHub releases page, where the lists of issues addressed per release are published. There is no changelog file in the repository itself, so the release notes on GitHub are the place to read before upgrading a minor version.

The security reporting process is also documented: vulnerabilities go through the security policy in the spring-projects GitHub organisation rather than through public issues.

Which module to depend on, and the alternative

The module split has a direct effect on your dependency list, and choosing badly is the most common mistake here.

If your application talks to RabbitMQ, the RabbitMQ implementation module is what carries the broker specific behaviour, and the client module carries the RabbitMQ Java client itself. If you only need the generic AMQP abstractions, for example because you write against the interface and inject a different implementation, the generic module is enough. The BOM module exists so the versions of the family cannot drift apart.

The alternative to this whole approach is to use the RabbitMQ Java client directly, without the Spring layer. The difference in approach is that the Spring AMQP modules give you the protocol wrapped in Spring conventions: beans instead of manually constructed objects, the configuration model of a Spring application, and the test support modules that let you exercise a consumer without a live broker. Using the client directly means fewer abstractions and fewer dependencies, and it means you write the plumbing around connection creation, error handling and recovery yourself.

For a Spring Boot application, the first option is usually less code and fewer surprises. For a plain Java service or a library that must not drag Spring into a consumer application, the client on its own is the better fit.

The licence is the Apache Software License version 2.0, stated in the README and covered by the LICENSE.txt file at the root of the repository. That is a permissive licence which allows use in proprietary products, with the notice and licence obligations attached. Whether it fits your organisation is a matter for your own legal review.

Editorial conclusion

Spring AMQP is the right dependency for a Spring Boot service that needs message queuing with RabbitMQ and wants the same configuration model, error handling and test support as the rest of the application, and picking the right module matters because the generic AMQP layer and the RabbitMQ implementation ship separately. It is the wrong choice for a non Spring Java service, where the RabbitMQ client on its own carries less, and for a project that only needs AMQP 1.0 or another broker, since this project is scoped to AMQP 0.9.1. Verify first that the 4.x line you depend on is the one your Spring Boot version manages, because the 4.2 milestones are still in preview, and read the release notes on GitHub before upgrading across a minor version.

Frequently asked questions

Official sources

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