Starter & Abhängigkeitsverwaltung
Wie Starter Abhängigkeiten bündeln und wie der Boot-Parent Versionen verwaltet, damit du sie nie von Hand auswählst.
Deutsche Übersetzung in Arbeit
Diese Lektion ist noch nicht ins Deutsche übersetzt und wird daher auf Englisch angezeigt. Der Rest der Seite ist vollständig lokalisiert.
Auf dieser Seite
Building a real feature usually means pulling together several libraries that must all work at compatible versions. Want to build a web API the old way? You'd need Spring MVC, an embedded server, a JSON library, a validation library, logging - each at a version that plays nicely with the others. Picking those by hand is tedious and a classic source of "it worked yesterday" breakage.
Starters solve this.
What a starter is
A starter is a curated, empty-ish dependency whose only job is to pull in a coherent set of other dependencies for one capability. You add one artifact and get everything that feature needs, at versions guaranteed to fit together.
<!-- This single line brings in Spring MVC, embedded Tomcat,
Jackson (JSON), validation, and logging - all version-aligned. -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>Cooking a dish from scratch means a shopping trip for a dozen ingredients in the
right quantities, hoping they combine well. A meal kit arrives with exactly the
right ingredients, pre-measured and tested to work together - you just cook. A
starter is a meal kit for a capability: spring-boot-starter-web is "everything you
need to serve HTTP," pre-portioned and known to fit.
The starters you'll meet in BookVault
Each module adds one starter as BookVault grows:
| Starter | Brings |
|---|---|
spring-boot-starter-web | Spring MVC, embedded Tomcat, JSON, validation |
spring-boot-starter-data-jpa | Spring Data JPA, Hibernate, a connection pool |
spring-boot-starter-security | Spring Security |
spring-boot-starter-actuator | Production endpoints (health, metrics) |
spring-boot-starter-test | JUnit 5, Mockito, AssertJ, Spring test support |
Notice you never wrote a version number for any of them.
Dependency management: no version numbers
That's the second half of the story. BookVault's build inherits from the Spring Boot parent (Maven) or applies the dependency-management plugin (Gradle), which supplies a curated list - a Bill of Materials (BOM) of versions for Boot and hundreds of common libraries.
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>4.0.0</version>
</parent>
<!-- No <version> needed here - the parent's BOM decides it. -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>One version to rule them all
Upgrading Spring Boot is usually a one-line change - bump the parent/plugin version. The BOM shifts every managed library to a tested-together set in lockstep, so you avoid the misery of hand-reconciling dozens of transitive versions.
A colleague new to Spring Boot is confused: your pom.xml lists
spring-boot-starter-web with no <version>, yet the build resolves a specific
version and compiles fine. Explain where the version comes from, and what single
change would upgrade that (and every other managed dependency) at once.
Why do Spring Boot starters usually not require you to specify version numbers?
Key takeaways
- A starter is a curated dependency that pulls in everything needed for one capability, at compatible versions - add one artifact, get the whole bundle.
- spring-boot-starter-web, -data-jpa, -security, -actuator, and -test are the ones BookVault adds module by module.
- The Spring Boot parent (Maven) or dependency-management plugin (Gradle) provides a BOM, so you omit version numbers on managed dependencies.
- Upgrading Boot is typically a one-line version bump that moves every managed library to a tested-together set.