Spring Framework's README publishes no coordinates and sends artifact access to a wiki

Every actionable section in the README resolves to a wiki page

Read this README looking for an install command and you will not find one. It runs to 226 words, and it contains no instructions of its own. Access to Binaries points at the artifacts wiki. Build from Source points at a section of the CONTRIBUTING.md file in the repository. Micro-Benchmarks points at a wiki page. The consequence is that the instructions for obtaining the artifact live on a wiki page rather than in the repository's own files. If your question is which version to depend on, this file will not answer it.

No coordinates, no version, and a framework-bom the README never mentions

Not one Maven coordinate, group identifier or version string appears anywhere in the README. For a library whose primary distribution channel is an artifact repository, that is a striking omission, and it puts the answer outside the project. The tree does contain a module named framework-bom, sitting alongside framework-api, framework-docs and framework-platform, and the README mentions only framework-docs, as the link to the reference documentation source; framework-bom, framework-api and framework-platform are not mentioned. A bill of materials is precisely the artifact that resolves versions across a multi-module release, so its presence in the tree while being absent from the documentation is the gap worth naming. The practical consequence is that anyone adding this to a build has to leave the repository to find out how, and the questions people bring to this project land on exactly that, since adding the dependency and understanding what the bom module does are both left open.

A patch release and two milestones sit in one list

The three most recent releases are v7.1.0-RC1 and v7.0.10, both from 2026-10-22, and v7.1.0-M2 from 2026-09-24. Two things fall out of those three lines. The first is that milestone tags are published into the same list as production patches, and a milestone is by definition not what you want on a production classpath. The second is the timestamps: the RC1 release candidate and the 7.0.10 patch are six seconds apart, which suggests they were published together. The consequence is for automation. Any script that resolves the newest release tag and treats it as the current stable version can pick up a milestone, and nothing in the list marks intent at a glance. Read the tag suffix rather than the date order when you pin this.

Twenty-two spring- modules, with the servlet and reactive stacks split apart

The top level is where the shape of the framework becomes concrete, and it is a long list. Counting the spring- prefixed directories gives twenty-two, running from spring-core and spring-beans through spring-aop, spring-expression, spring-context, spring-tx, spring-jdbc, spring-orm, spring-messaging, spring-jms, spring-oxm, spring-r2dbc and spring-test, up to the web tier. At that tier the split that matters is visible: spring-webmvc and spring-webflux are separate modules, as are spring-web and spring-websocket. The consequence is that the artifact you depend on is one of twenty-two, and choosing between the servlet stack and the reactive stack is a choice between two different modules rather than a configuration flag. Two more entries are easy to misread: spring-context-indexer is a build-time concern rather than a runtime one, and spring-core-test is not the same thing as spring-test. None of this is mapped in the README.

Gradle, a committed wrapper, and a committed .idea directory

The build is Gradle and the wrapper is committed: build.gradle and settings.gradle at the root, a buildSrc directory, gradle.properties, a gradle directory, and both gradlew and gradlew.bat. Committing the wrapper means a contributor does not install Gradle, but it also means the Gradle version is whatever the wrapper configuration says, and no README section mentions it. Two other top-level entries say something about the intended audience. A .sdkmanrc is present, which is the file that pins a JDK version for contributors, and .idea is committed, which is an IntelliJ project directory. Neither is explained. The two import-into-eclipse and import-into-intellij-idea markdown files at the root complete the picture: the expected development workflow appears to be importing the source into an IDE, not consuming a published artifact, so anyone expecting a quick dependency is looking at the wrong repository for the wrong task.

The project concedes that the name covers more than this repository

The README makes a naming point explicitly rather than leaving it implied. It describes this repository as the home of the Spring Framework and the foundation for all Spring projects, then notes that the framework and the family of Spring projects are collectively often referred to simply as Spring. So the project itself accepts that the word does not identify a repository. The consequence is practical for anyone arriving with a question instead of a link. Asking what Spring is, whether the framework is outdated, or how it differs from Spring Boot does not resolve to this file, which describes neither Boot nor the wider family and redirects to a reference overview. Nothing here tells you whether you need the framework directly rather than a higher-level starter, and the module list offers no obvious answer. Treat this as one layer of a larger stack rather than as the thing named Spring.

Three documentation surfaces, and the wiki carries the load-bearing parts

Documentation is spread across three places with very different durability. The reference documentation is written in the repository, with its source in the framework-docs module, published alongside a Javadoc API reference. Guides and tutorials live across the wider set of Spring projects rather than here. GitHub wiki pages form a third surface, and that is the one the README leans on for artifacts and micro-benchmarks. The mismatch is the point. The versioned, reviewable documentation sits in the repository, while artifact access and benchmark notes sit on the wiki.

Editorial conclusion

Adopt Spring Framework when you are working on the framework layer itself, where the committed Gradle build, the twenty-two module boundaries and the reference documentation in framework-docs are all worth having in the repository. Do not come to it for setup help: it publishes no coordinates, no version and no build command, and sends artifact access to a wiki page that sits outside the code, with build steps pointed to CONTRIBUTING.md. Two things to check before you rely on the releases list. Milestone and release-candidate tags such as 7.1.0-M2 and 7.1.0-RC1 are published alongside production patches, so read the tag suffix rather than trusting the newest date. And confirm the version yourself, because the README will not tell you and the framework-bom module that would resolve it is in the tree without a mention in the documentation.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes