Verpacken & Ausführen
Das ausführbare Fat-Jar, Layered Jars, Cloud-Native Buildpacks und BookVault als eigenständige Anwendung ausführen.
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
Your app runs on your machine. Now it has to run everywhere else - a test server, a container, production. Spring Boot's packaging model makes that almost trivial: the build produces one self-contained, runnable artifact.
The executable "fat jar"
Traditional Java apps ship a thin jar plus a folder of dependency jars you must
assemble on the target machine. Spring Boot instead builds a single executable jar
that contains your code, every dependency, and a small launcher - runnable with plain
java -jar:
./mvnw clean package # or: ./gradlew bootJar
java -jar target/bookvault-0.0.1-SNAPSHOT.jarThe Spring Boot build plugin does the packaging. It's already in a generated project:
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>Deploying a thin jar plus loose dependencies is like opening a restaurant: at every new location you install the kitchen, plumbing, and wiring before you can cook. A fat jar is a food truck - the whole kitchen is built in and travels as one unit. Park it anywhere with power (a JVM) and you're serving. That "one unit you can run anywhere" is why Boot pairs so naturally with containers.
Layered jars & containers
A fat jar is one file, but inside, Boot organizes contents into layers that change at different rates - dependencies (rarely change) separate from your application code (changes every build). Docker builds cache unchanged layers, so rebuilding an image after a code change re-ships only the tiny application layer, not hundreds of megabytes of dependencies.
You don't even need to write a Dockerfile. The build can produce an optimized image directly using Cloud-Native Buildpacks:
./mvnw spring-boot:build-image # or: ./gradlew bootBuildImage
docker run -p 8080:8080 docker.io/library/bookvault:0.0.1-SNAPSHOTRun the same artifact everywhere
The jar you test locally is byte-for-byte the jar that runs in production - only configuration changes between environments (via profiles and environment variables from the configuration lesson). Same artifact, different dials: that's what makes Boot deployments predictable.
Where BookVault stands now
With this module complete, BookVault boots on an embedded server, answers
/api/books, reports /actuator/health, is configured per environment, and packages
into a runnable jar. That's a real, deployable service - it just has a hard-coded
catalog. The Web module makes the API real, and Data gives it a database.
Explain why Spring Boot's layered fat jar makes Docker image rebuilds fast after a small code change. Which layer is re-shipped, and which large layer is served from cache?
What is a Spring Boot executable ('fat') jar?
Key takeaways
- The Spring Boot build plugin produces a single executable 'fat' jar - your code plus all dependencies - runnable with java -jar.
- Inside, contents are organized into layers by change frequency, so Docker rebuilds re-ship only the small application layer.
- spring-boot:build-image / bootBuildImage creates an optimized container image via Cloud-Native Buildpacks - no Dockerfile needed.
- The same artifact runs in every environment; only configuration changes, keeping deployments predictable.
- After this module BookVault boots, serves /api/books and /actuator/health, is profile-configured, and packages to a runnable jar.