Spring Framework: what the repository actually contains, and how to add it to a Java build

What Spring Framework is, and who ends up depending on it

The README describes the project as "the foundation for all Spring projects", and the top-level directory listing backs that up: spring-core, spring-beans, spring-context, spring-aop, spring-expression, spring-jdbc, spring-tx, spring-orm, spring-oxm, spring-jms, spring-messaging, spring-web, spring-webmvc, spring-webflux, spring-websocket, spring-r2dbc, spring-test and more, each a separate module with its own artifact. Nothing here is a single monolithic jar. That layout is the first thing to internalize: when someone says they added Spring to a project, they added a subset.

The problem it solves is object wiring and cross-cutting behaviour in plain Java. Without a container, an enterprise application ends up constructing its own dependency graph by hand, scattering configuration reads, transaction boundaries and connection handling through business code. Spring Framework supplies an inversion-of-control container that builds and connects objects from configuration, an AOP layer that applies behaviour such as transactions or security around method calls, and abstractions over JDBC, ORM, messaging and web transport so that application code talks to interfaces instead of vendor APIs.

The audience is narrower than the download numbers suggest. It is for Java engineers building long-lived server-side systems, for teams maintaining applications written before Spring Boot existed, and for people writing libraries or frameworks that need dependency injection without dictating an application runtime. If you are writing a small command-line tool, the container is overhead you will not recover.

The module graph, and why spring-context is not spring-core

The architecture visible in the repository is layered. spring-core and spring-beans carry the fundamental pieces: resource loading, type conversion and the BeanFactory. spring-context sits on top and adds the ApplicationContext, annotation-driven configuration, event publication and the lifecycle callbacks most applications actually use. spring-aop and spring-expression support the proxying and expression evaluation that annotation-based configuration depends on. Above that, the integration and web modules branch out: spring-jdbc and spring-tx for data access and transaction demarcation, spring-orm for JPA and Hibernate integration, spring-web for transport-neutral web abstractions, then two parallel web stacks in spring-webmvc (servlet, thread-per-request) and spring-webflux (reactive, built on the reactive streams model).

That split matters when you assemble a build. Declaring spring-context does not automatically pull in the web stack, and declaring spring-webmvc does not give you a servlet container. The repository also contains framework-bom and framework-platform, which exist to align versions across these artifacts so you do not end up with spring-core from one release and spring-tx from another. The documentation points readers to the Overview section of the reference documentation for a fuller introduction, and to the Artifacts wiki page for distribution zips and artifact access.

A design consequence worth naming: because the modules are genuinely separable, it is possible to run the container without the web layer, or the web layer without the ORM integration. That flexibility is also a trap. Nothing in the build stops you from adding a module whose transitive requirements you have not thought through, and the failure usually surfaces at runtime as a missing class rather than at compile time.

Installing Spring Framework: where the repository tells you to get it

The README does not give install steps. It points to the Spring Framework Artifacts wiki page for access to artifacts or a distribution zip, and to the Build from Source wiki page, together with CONTRIBUTING.md, for compiling the framework itself. For normal use you do not build from source; you consume published artifacts through a build tool. The repository contains gradlew and gradlew.bat plus build.gradle and settings.gradle, which is how the framework compiles its own modules, not how your application consumes it.

The module coordinates follow the repository layout: the artifacts sit under the org.springframework groupId, and the artifact names match the top-level directories, so spring-context is the module directory spring-context/ and spring-webmvc is spring-webmvc/. The repository listing also includes framework-bom and framework-platform, which the README does not describe in detail but which exist alongside the module directories. Which version to declare, and whether your chosen line is still supported, is answered on the project's release pages rather than in the README, so check there before pinning anything.

A first real use starts with the container. The framework's annotation-driven configuration is what most readers mean by "using Spring", and the entry point is the ApplicationContext that spring-context provides. You declare a configuration class, ask the context for a bean by type, and close the context when you are done. You should see the container instantiate the bean and hand it back. If the bean is not found, the context throws at lookup; if a dependency is missing, it fails at startup with an unsatisfied dependency message naming the constructor. That failure-at-startup behaviour is the container doing its job, and it is worth reading those messages rather than guessing.

Where Spring Framework is the wrong tool

The most common mismatch is choosing the framework when the reader actually wants Spring Boot. Search interest in "spring framework vs spring boot" reflects real confusion, and the difference is concrete: Spring Framework gives you the container and the web stacks, but you supply the servlet container, the dependency versions, the property loading and the application entry point. Spring Boot is a separate project that layers auto-configuration and starters on top. If your goal is a running service with an embedded server and sensible defaults, starting from spring-context and spring-webmvc means writing configuration that Boot would have generated. Nothing in this repository replaces that.

A second mismatch is scale. For a single-class utility, or a batch job with three objects and no cross-cutting concerns, the container adds indirection you will pay for in startup time and in stack traces that pass through proxy and interceptor frames before reaching your code. Constructor injection is pleasant; it is not free.

The third is version discipline. The repository shows a 7.x line in progress alongside 7.0.x maintenance releases, and the search data includes people asking about end of life and end of support. The README itself does not state support windows; that information lives on the project's release and support pages. Teams that pin a major version and never revisit it are the ones who discover the support boundary late, when a CVE forces an upgrade across several modules at once. Because the modules are separate artifacts, an upgrade is rarely a single version bump, which is exactly why the BOM exists.

Spring Boot and Quarkus as alternatives, and what actually differs

Spring Boot is the alternative most teams evaluate, and it is not a competitor in the usual sense: it is built on Spring Framework. The difference in approach is who owns the configuration. With Spring Framework you declare the container, choose and version every module, and wire the web layer to a servlet container you provide. With Spring Boot you add a starter, get an embedded server, auto-configuration driven by what is on the classpath, and externalized configuration from properties files and environment variables. If you are deciding between them, the question is whether you want to own the assembly. Owning it is reasonable when you are embedding the container inside a larger host, when you need a runtime Boot does not target, or when you are publishing a library that cannot assume a boot runtime.

Quarkus is the different-approach alternative: it targets GraalVM native images and build-time initialization, moving work that Spring does at startup into the build. That trade shows up as faster startup and lower memory in native mode, against a programming model that is not source-compatible with Spring's annotations and a build step that constrains what can happen at runtime. If your workload is long-running and JVM-hosted, the startup difference is largely irrelevant and the migration cost is hard to justify. If you are packing many short-lived processes, it is worth measuring rather than assuming.

A third path is worth mentioning because it is often the honest answer: for a small service, plain Java with a lightweight HTTP library and manual wiring has no container, no proxy layer and no version alignment problem. Spring Framework wins when the object graph and the cross-cutting concerns grow past what you want to maintain by hand.

Maintenance, upgrade cost and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-08-20, so the project is being worked on. The release list shows v7.1.0-M1 and v7.0.9 both dated 2026-08-20, with v7.0.8 on 2026-06-08. A milestone alongside a patch release on the same day is normal for this project and tells you the 7.0.x line is receiving maintenance while 7.1 is in development. The README does not document rollback, downgrade paths or support windows, so treat any claim about how long a given line stays supported as something to confirm on the project's own release pages rather than infer from the README.

Upgrade cost is dominated by the module split. Moving a major version can mean touching spring-core, spring-context, spring-web, spring-webmvc and spring-tx together, plus whatever ORM or messaging integration you use, plus any third-party library compiled against the previous line. The framework-bom and framework-platform entries in the repository exist to reduce the alignment half of that work; they do not reduce the API-compatibility half. If you maintain a library that other teams depend on, your upgrade cadence becomes their upgrade cadence, which is a reason to keep the surface you expose small.

The licence is Apache-2.0, stated in the README and present as LICENSE.txt at the repository root. That is a permissive licence with an explicit patent grant and no copyleft obligation on your own code. It does not tell you anything about the licences of the third-party libraries your chosen modules pull in, and those are separate. This is not legal advice; if your organization has licence review, the module list is the input that review needs, which is another practical reason to keep the dependency set minimal.

Editorial conclusion

Adopt Spring Framework when you want the IoC container, AOP or the web stacks without Spring Boot's opinionated auto-configuration, when you are maintaining a legacy XML-configured application, or when you are building a library or framework that must not force a boot runtime on its users. Do not adopt it if what you actually want is a runnable application with embedded server, externalized config and starters: that is Spring Boot, and assembling the equivalent by hand from spring-context, spring-webmvc and a servlet container is work Boot already did. Do not pick it for a short-lived script or a small CLI; the container earns its cost only when you have many collaborating objects with cross-cutting concerns. Before committing, verify three things against the reference documentation rather than a blog post: which module coordinates your build needs (spring-core, spring-beans and spring-context are separate artifacts), whether your chosen release line is still inside the support window described on the project's release pages, and how you will manage versions across modules. The framework-bom entry in the repository listing exists precisely for that last point, and using it is cheaper than pinning each artifact by hand.

Frequently asked questions

Official sources

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