Browse Source
Documentation for native executables, CDS, and checkpoint/restore are now under a common heading in the reference documentation, along with sections on building container images. A few sections containing prescriptive workflows have been moved from reference to how-to guides. This consolidates and improves the consistency of recommendations on how to package and run applications. Closes gh-40977pull/39957/head
Scott Frederick
2 years ago
50 changed files with 393 additions and 381 deletions
@ -1,4 +1,4 @@
@@ -1,4 +1,4 @@
|
||||
[[deployment]] |
||||
[[howto.deployment]] |
||||
= Deploying Spring Boot Applications |
||||
|
||||
Spring Boot's flexible packaging options provide a great deal of choice when it comes to deploying your application. |
||||
@ -0,0 +1,7 @@
@@ -0,0 +1,7 @@
|
||||
[[howto.native-image]] |
||||
= GraalVM Native Applications |
||||
|
||||
This section contains details on developing and testing Spring Boot applications as GraalVM native images. |
||||
|
||||
TIP: For an overview of GraalVM native image concepts, see the xref:reference:packaging/native-image/introducing-graalvm-native-images.adoc[Introducing GraalVM Native Images] section. |
||||
|
||||
@ -1,4 +0,0 @@
@@ -1,4 +0,0 @@
|
||||
[[container-images]] |
||||
= Container Images |
||||
|
||||
Spring Boot applications can be containerized xref:container-images/dockerfiles.adoc[using Dockerfiles], or by xref:container-images/cloud-native-buildpacks.adoc[using Cloud Native Buildpacks to create optimized docker compatible container images that you can run anywhere]. |
||||
@ -1,110 +0,0 @@
@@ -1,110 +0,0 @@
|
||||
[[deployment.efficient]] |
||||
= Efficient Deployments |
||||
|
||||
|
||||
|
||||
[[deployment.efficient.unpacking]] |
||||
== Unpacking the Executable JAR |
||||
|
||||
You can run your application using the executable jar, but loading the classes from nested jars has a small cost. |
||||
Depending on the size of the jar, running the application from an exploded structure is faster and recommended in production. |
||||
Certain PaaS implementations may also choose to extract archives before they run. |
||||
For example, Cloud Foundry operates this way. |
||||
|
||||
Spring Boot supports extracting your application to a directory using different layouts. |
||||
The default layout is the most efficient, and is xref:#deployment.efficient.cds[CDS friendly]. |
||||
|
||||
In this layout, the libraries are extracted to a `lib/` folder, and the application JAR |
||||
contains the application classes and a manifest which references the libraries in the `lib/` folder. |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ java -Djarmode=tools -jar my-app.jar extract |
||||
$ java -jar my-app/my-app.jar |
||||
---- |
||||
|
||||
After startup, you should not expect any differences. |
||||
|
||||
TIP: Run `java -Djarmode=tools -jar my-app.jar help extract` to see all possible options. |
||||
|
||||
|
||||
[[deployment.efficient.cds]] |
||||
== Optimize Startup Time with CDS |
||||
|
||||
Class Data Sharing (CDS) is a https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html[JVM feature] that can help reduce the startup time and memory footprint of Java applications. |
||||
|
||||
To use it, you should first perform a training run on your application in exploded form: |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ java -Djarmode=tools -jar my-app.jar extract --destination application |
||||
$ cd application |
||||
$ java -XX:ArchiveClassesAtExit=application.jsa -Dspring.context.exit=onRefresh -jar my-app.jar |
||||
---- |
||||
|
||||
This creates an `application.jsa` file that can be reused as long as the application is not updated. |
||||
|
||||
To use the cache, you need to add an extra parameter when starting the application: |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ java -XX:SharedArchiveFile=application.jsa -jar my-app.jar |
||||
---- |
||||
|
||||
NOTE: For more details about CDS, refer to the {url-spring-framework-docs}/integration/cds.html[Spring Framework reference documentation] |
||||
|
||||
|
||||
[[deployment.efficient.aot]] |
||||
== Using Ahead-of-time Processing With the JVM |
||||
|
||||
It's beneficial for the startup time to run your application using the AOT generated initialization code. |
||||
First, you need to ensure that the jar you are building includes AOT generated code. |
||||
|
||||
NOTE: CDS and AOT can be combined to further improve startup time. |
||||
|
||||
For Maven, this means that you should build with `-Pnative` to activate the `native` profile: |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ mvn -Pnative package |
||||
---- |
||||
|
||||
For Gradle, you need to ensure that your build includes the `org.springframework.boot.aot` plugin. |
||||
|
||||
When the JAR has been built, run it with `spring.aot.enabled` system property set to `true`. For example: |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ java -Dspring.aot.enabled=true -jar myapplication.jar |
||||
|
||||
........ Starting AOT-processed MyApplication ... |
||||
---- |
||||
|
||||
Beware that using the ahead-of-time processing has drawbacks. |
||||
It implies the following restrictions: |
||||
|
||||
* The classpath is fixed and fully defined at build time |
||||
* The beans defined in your application cannot change at runtime, meaning: |
||||
- The Spring `@Profile` annotation and profile-specific configuration xref:how-to:aot.adoc#howto.aot.conditions[have limitations]. |
||||
- Properties that change if a bean is created are not supported (for example, `@ConditionalOnProperty` and `.enable` properties). |
||||
|
||||
To learn more about ahead-of-time processing, please see the xref:native-image/introducing-graalvm-native-images.adoc#native-image.introducing-graalvm-native-images.understanding-aot-processing[Understanding Spring Ahead-of-Time Processing section]. |
||||
|
||||
|
||||
|
||||
[[deployment.efficient.checkpoint-restore]] |
||||
== Checkpoint and Restore With the JVM |
||||
|
||||
https://wiki.openjdk.org/display/crac/Main[Coordinated Restore at Checkpoint] (CRaC) is an OpenJDK project that defines a new Java API to allow you to checkpoint and restore an application on the HotSpot JVM. |
||||
It is based on https://github.com/checkpoint-restore/criu[CRIU], a project that implements checkpoint/restore functionality on Linux. |
||||
|
||||
The principle is the following: you start your application almost as usual but with a CRaC enabled version of the JDK like https://bell-sw.com/pages/downloads/?package=jdk-crac[BellSoft Liberica JDK with CRaC] or https://www.azul.com/downloads/?package=jdk-crac#zulu[Azul Zulu JDK with CRaC]. |
||||
Then at some point, potentially after some workloads that will warm up your JVM by executing all common code paths, you trigger a checkpoint using an API call, a `jcmd` command, an HTTP endpoint, or a different mechanism. |
||||
|
||||
A memory representation of the running JVM, including its warmness, is then serialized to disk, allowing a fast restoration at a later point, potentially on another machine with a similar operating system and CPU architecture. |
||||
The restored process retains all the capabilities of the HotSpot JVM, including further JIT optimizations at runtime. |
||||
|
||||
Based on the foundations provided by Spring Framework, Spring Boot provides support for checkpointing and restoring your application, and manages out-of-the-box the lifecycle of resources such as socket, files and thread pools https://github.com/spring-projects/spring-lifecycle-smoke-tests/blob/main/STATUS.adoc[on a limited scope]. |
||||
Additional lifecycle management is expected for other dependencies and potentially for the application code dealing with such resources. |
||||
|
||||
You can find more details about the two modes supported ("on demand checkpoint/restore of a running application" and "automatic checkpoint/restore at startup"), how to enable checkpoint and restore support and some guidelines in {url-spring-framework-docs}/integration/checkpoint-restore.html[the Spring Framework JVM Checkpoint Restore support documentation]. |
||||
@ -1,3 +1,3 @@
@@ -1,3 +1,3 @@
|
||||
= Reference |
||||
|
||||
This section provides information on using the feature and capabilities of Spring Boot. |
||||
This section provides information on using the features and capabilities of Spring Boot. |
||||
|
||||
@ -0,0 +1,35 @@
@@ -0,0 +1,35 @@
|
||||
[[packaging.aot]] |
||||
= Ahead-of-time Processing With the JVM |
||||
|
||||
It's beneficial for the startup time to run your application using the AOT generated initialization code. |
||||
First, you need to ensure that the jar you are building includes AOT generated code. |
||||
|
||||
NOTE: CDS and AOT can be combined to further improve startup time. |
||||
|
||||
For Maven, this means that you should build with `-Pnative` to activate the `native` profile: |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ mvn -Pnative package |
||||
---- |
||||
|
||||
For Gradle, you need to ensure that your build includes the `org.springframework.boot.aot` plugin. |
||||
|
||||
When the JAR has been built, run it with `spring.aot.enabled` system property set to `true`. For example: |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ java -Dspring.aot.enabled=true -jar myapplication.jar |
||||
|
||||
........ Starting AOT-processed MyApplication ... |
||||
---- |
||||
|
||||
Beware that using the ahead-of-time processing has drawbacks. |
||||
It implies the following restrictions: |
||||
|
||||
* The classpath is fixed and fully defined at build time |
||||
* The beans defined in your application cannot change at runtime, meaning: |
||||
- The Spring `@Profile` annotation and profile-specific configuration xref:how-to:aot.adoc#howto.aot.conditions[have limitations]. |
||||
- Properties that change if a bean is created are not supported (for example, `@ConditionalOnProperty` and `.enable` properties). |
||||
|
||||
To learn more about ahead-of-time processing, please see the xref:packaging/native-image/introducing-graalvm-native-images.adoc#packaging.native-image.introducing-graalvm-native-images.understanding-aot-processing[Understanding Spring Ahead-of-Time Processing] section. |
||||
@ -0,0 +1,16 @@
@@ -0,0 +1,16 @@
|
||||
[[packaging.checkpoint-restore]] |
||||
= Checkpoint and Restore With the JVM |
||||
|
||||
https://wiki.openjdk.org/display/crac/Main[Coordinated Restore at Checkpoint] (CRaC) is an OpenJDK project that defines a new Java API to allow you to checkpoint and restore an application on the HotSpot JVM. |
||||
It is based on https://github.com/checkpoint-restore/criu[CRIU], a project that implements checkpoint/restore functionality on Linux. |
||||
|
||||
The principle is the following: you start your application almost as usual but with a CRaC enabled version of the JDK like https://bell-sw.com/pages/downloads/?package=jdk-crac[BellSoft Liberica JDK with CRaC] or https://www.azul.com/downloads/?package=jdk-crac#zulu[Azul Zulu JDK with CRaC]. |
||||
Then at some point, potentially after some workloads that will warm up your JVM by executing all common code paths, you trigger a checkpoint using an API call, a `jcmd` command, an HTTP endpoint, or a different mechanism. |
||||
|
||||
A memory representation of the running JVM, including its warmness, is then serialized to disk, allowing a fast restoration at a later point, potentially on another machine with a similar operating system and CPU architecture. |
||||
The restored process retains all the capabilities of the HotSpot JVM, including further JIT optimizations at runtime. |
||||
|
||||
Based on the foundations provided by Spring Framework, Spring Boot provides support for checkpointing and restoring your application, and manages out-of-the-box the lifecycle of resources such as socket, files and thread pools https://github.com/spring-projects/spring-lifecycle-smoke-tests/blob/main/STATUS.adoc[on a limited scope]. |
||||
Additional lifecycle management is expected for other dependencies and potentially for the application code dealing with such resources. |
||||
|
||||
You can find more details about the two modes supported ("on demand checkpoint/restore of a running application" and "automatic checkpoint/restore at startup"), how to enable checkpoint and restore support and some guidelines in {url-spring-framework-docs}/integration/checkpoint-restore.html[the Spring Framework JVM Checkpoint Restore support documentation]. |
||||
@ -0,0 +1,24 @@
@@ -0,0 +1,24 @@
|
||||
[[packaging.class-data-sharing]] |
||||
= Class Data Sharing |
||||
|
||||
Class Data Sharing (CDS) is a https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html[JVM feature] that can help reduce the startup time and memory footprint of Java applications. |
||||
|
||||
To use it, you should first perform a training run on your application in exploded form: |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ java -Djarmode=tools -jar my-app.jar extract --destination application |
||||
$ cd application |
||||
$ java -XX:ArchiveClassesAtExit=application.jsa -Dspring.context.exit=onRefresh -jar my-app.jar |
||||
---- |
||||
|
||||
This creates an `application.jsa` file that can be reused as long as the application is not updated. |
||||
|
||||
To use the cache, you need to add an extra parameter when starting the application: |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ java -XX:SharedArchiveFile=application.jsa -jar my-app.jar |
||||
---- |
||||
|
||||
NOTE: For more details about CDS, refer to the {url-spring-framework-docs}/integration/cds.html[Spring Framework reference documentation] |
||||
@ -1,16 +1,16 @@
@@ -1,16 +1,16 @@
|
||||
[[container-images.efficient-images]] |
||||
[[packaging.container-images.efficient-images]] |
||||
= Efficient Container Images |
||||
|
||||
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. |
||||
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 an 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 not 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. |
||||
|
||||
|
||||
|
||||
[[container-images.efficient-images.layering]] |
||||
[[packaging.container-images.efficient-images.layering]] |
||||
== Layering Docker Images |
||||
|
||||
To make it easier to create optimized Docker images, Spring Boot supports adding a layer index file to the jar. |
||||
@ -0,0 +1,4 @@
@@ -0,0 +1,4 @@
|
||||
[[packaging.container-images]] |
||||
= Container Images |
||||
|
||||
Spring Boot applications can be containerized xref:packaging/container-images/dockerfiles.adoc[using Dockerfiles], or by xref:packaging/container-images/cloud-native-buildpacks.adoc[using Cloud Native Buildpacks] to create optimized docker compatible container images that you can run anywhere. |
||||
@ -0,0 +1,30 @@
@@ -0,0 +1,30 @@
|
||||
[[packaging.efficient]] |
||||
= Efficient Deployments |
||||
|
||||
|
||||
|
||||
[[packaging.efficient.unpacking]] |
||||
== Unpacking the Executable JAR |
||||
|
||||
You can run your application using the executable jar, but loading the classes from nested jars has a small startup cost. |
||||
Depending on the size of the jar, running the application from an exploded structure is faster and recommended in production. |
||||
Certain PaaS implementations may also choose to extract archives before they run. |
||||
For example, Cloud Foundry operates this way. |
||||
|
||||
Spring Boot supports extracting your application to a directory using different layouts. |
||||
The default layout is the most efficient, and is xref:#deployment.efficient.cds[CDS friendly]. |
||||
|
||||
In this layout, the libraries are extracted to a `lib/` folder, and the application JAR |
||||
contains the application classes and a manifest which references the libraries in the `lib/` folder. |
||||
|
||||
[source,shell] |
||||
---- |
||||
$ java -Djarmode=tools -jar my-app.jar extract |
||||
$ java -jar my-app/my-app.jar |
||||
---- |
||||
|
||||
After startup, you should not expect any differences in execution time between running an executable jar and running an extracted jar. |
||||
|
||||
TIP: Run `java -Djarmode=tools -jar my-app.jar help extract` to see all possible options. |
||||
|
||||
|
||||
@ -0,0 +1,7 @@
@@ -0,0 +1,7 @@
|
||||
[[packaging]] |
||||
= Packaging Spring Boot Applications |
||||
|
||||
Spring Boot supports several technologies for optimizing applications for deployment, including xref:packaging/native-image/index.adoc[GraalVM native images], xref:packaging/class-data-sharing.adoc[Class Data Sharing], and xref:packaging/checkpoint-restore.adoc[Checkpoint and Restore]. |
||||
|
||||
Spring Boot applications can be packaged in Docker containers using techniques described in xref:packaging/container-images/index.adoc[Container Images]. |
||||
|
||||
@ -1,5 +1,5 @@
@@ -1,5 +1,5 @@
|
||||
[[native-image]] |
||||
= GraalVM Native Image Support |
||||
[[packaging.native-image]] |
||||
= GraalVM Native Images |
||||
|
||||
https://www.graalvm.org/native-image/[GraalVM Native Images] are standalone executables that can be generated by processing compiled Java applications ahead-of-time. |
||||
Native Images generally have a smaller memory footprint and start faster than their JVM counterparts. |
||||
@ -1,8 +1,9 @@
@@ -1,8 +1,9 @@
|
||||
[[using.packaging-for-production]] |
||||
= Packaging Your Application for Production |
||||
|
||||
Executable jars can be used for production deployment. |
||||
As they are self-contained, they are also ideally suited for cloud-based deployment. |
||||
Once your Spring Boot application is ready for production deployment, there are many options for packaging and optimizing |
||||
the application. |
||||
See the xref:packaging/index.adoc[Packaging] section of the documentation to read about these features. |
||||
|
||||
For additional "`production ready`" features, such as health, auditing, and metric REST or JMX end-points, consider adding `spring-boot-actuator`. |
||||
See _xref:how-to:actuator.adoc[Actuator]_ for details. |
||||
For additional "production ready" features, such as health, auditing, and metric REST or JMX end-points, consider adding `spring-boot-actuator`. |
||||
See xref:how-to:actuator.adoc[Actuator] for details. |
||||
|
||||
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/developingyourfirstapplication/sampleapplication/MyApplication.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/howto/nativeimage/developingyourfirstapplication/sampleapplication/MyApplication.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/developingyourfirstapplication/sampleapplication/MyApplication.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/howto/nativeimage/developingyourfirstapplication/sampleapplication/MyApplication.java
6
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/customhints/testing/MyRuntimeHintsTests.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/customhints/testing/MyRuntimeHintsTests.java
6
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/customhints/testing/MyRuntimeHintsTests.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/customhints/testing/MyRuntimeHintsTests.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/MyProperties.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/MyProperties.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/MyProperties.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/MyProperties.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesCtor.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesCtor.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesCtor.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesCtor.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesRecord.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesRecord.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesRecord.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesRecord.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/Nested.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/Nested.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/Nested.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/Nested.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyBean.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyBean.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyBean.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyBean.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyConfiguration.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyConfiguration.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyConfiguration.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyConfiguration.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyConfiguration__BeanDefinitions.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyConfiguration__BeanDefinitions.java
4
spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyConfiguration__BeanDefinitions.java → spring-boot-project/spring-boot-docs/src/main/java/org/springframework/boot/docs/packaging/nativeimage/introducinggraalvmnativeimages/understandingaotprocessing/sourcecodegeneration/MyConfiguration__BeanDefinitions.java
2
spring-boot-project/spring-boot-docs/src/main/kotlin/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesKotlin.kt → spring-boot-project/spring-boot-docs/src/main/kotlin/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesKotlin.kt
2
spring-boot-project/spring-boot-docs/src/main/kotlin/org/springframework/boot/docs/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesKotlin.kt → spring-boot-project/spring-boot-docs/src/main/kotlin/org/springframework/boot/docs/packaging/nativeimage/advanced/nestedconfigurationproperties/MyPropertiesKotlin.kt
Loading…
Reference in new issue