While it is possible to convert a Spring Boot fat jar into a docker image with just a few lines in the Dockerfile, we will use the <<container-images#container-images.efficient-images.layering,layering feature>> to create an optimized docker image.
While it is possible to convert a Spring Boot uber jar into a docker image with just a few lines in the Dockerfile, we will use the <<container-images#container-images.efficient-images.layering,layering feature>> to create an optimized docker image.
When you create a jar containing the layers index file, the `spring-boot-jarmode-layertools` jar will be added as a dependency to your jar.
With this jar on the classpath, you can launch your application in a special mode which allows the bootstrap code to run something entirely different from your application, for example, something that extracts the layers.
It is easily possible to package a Spring Boot fat jar as a docker image.
However, there are various downsides to copying and running the fat jar as is in the docker image.
There’s always a certain amount of overhead when running a fat jar without unpacking it, and in a containerized environment this can be noticeable.
It is easily possible to package a Spring Boot uber jar as a docker image.
However, there are various downsides to copying and running the uber jar as is in the docker image.
There’s always a certain amount of overhead when running a uber jar without unpacking it, and in a containerized environment this can be noticeable.
The other issue is that putting your application's code and all its dependencies in one layer in the Docker image is sub-optimal.
Since you probably recompile your code more often than you upgrade the version of Spring Boot you use, it’s often better to separate things a bit more.
If you put jar files in the layer before your application classes, Docker often only needs to change the very bottom layer and can pick others up from its cache.
@ -272,7 +272,7 @@ When building with Maven, it is recommended to add the following dependency in a
</dependency>
----
If you have defined auto-configurations directly in your application, make sure to configure the `spring-boot-maven-plugin` to prevent the `repackage` goal from adding the dependency into the fat jar:
If you have defined auto-configurations directly in your application, make sure to configure the `spring-boot-maven-plugin` to prevent the `repackage` goal from adding the dependency into the uber jar:
We finish our example by creating a completely self-contained executable jar file that we could run in production.
Executable jars (sometimes called "`fat jars`") are archives containing your compiled classes along with all of the jar dependencies that your code needs to run.
Executable jars (sometimes called "`uber jars`" or "`fat jars`") are archives containing your compiled classes along with all of the jar dependencies that your code needs to run.
@ -9,7 +9,7 @@ This section describes those changes.
== Reacting to the Java Plugin
When Gradle's {java-plugin}[`java` plugin] is applied to a project, the Spring Boot plugin:
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an executable, fat jar for the project.
1. Creates a {boot-jar-javadoc}[`BootJar`] task named `bootJar` that will create an executable, uber jar for the project.
The jar will contain everything on the runtime classpath of the main source set; classes are packaged in `BOOT-INF/classes` and jars are packaged in `BOOT-INF/lib`
2. Configures the `assemble` task to depend on the `bootJar` task.
3. Configures the `jar` task to use `plain` as the convention for its archive classifier.