2

I have a spring-boot application. I checked a couple dockerfile example for sprint-boot application. No body does not build jar file in dockerfile but it is possible. Is there a unexpected thing that I missed.

I dont even see multistage builds in spring boot official docs

This is my Dockerfile, as you see I am using multistage build here. This is working fine

FROM maven:3-openjdk-18
COPY . .
RUN mvn clean package


FROM openjdk:19-alpine
VOLUME /tmp
COPY --from=0  target/*.jar app.jar
CMD ["java","-jar","/app.jar"]

My question is, Is this OK to use like this or Is there any important thing that I miss

feyzullahyildiz
  • 456
  • 4
  • 11
  • I really dont get this. What is wrong with my question – feyzullahyildiz Jan 24 '23 at 08:00
  • 1
    It's up to personal preference. Do what fits your workflow best. – Hans Kilian Jan 24 '23 at 08:40
  • `RUN mvn clean package` that statement will probably build a jar. It isn't clear what your question is. Are you saying, your docker file builds a jar, but people don't otherwise? – matt Jan 24 '23 at 10:39
  • You can follow my article to understand the best practices when building production-grade Dockerfile for Spring Boot. https://medium.com/codex/write-production-ready-optimized-dockerfile-for-spring-boot-application-8fec0906a894 – Ladu anand Jan 24 '23 at 10:39
  • This works, but will always have to download every dependency on each source change, since you're not persisting the downloads. This might be okay for CI usage (where you want as clean a build as possible), but for local development that can be a significant slowdown. – Joachim Sauer Jan 24 '23 at 10:39
  • I generally see that most people create jar outside of docker. After creating the jar they copy into the image to build an image. But we can do in a single dockerfile with multistage builds. – feyzullahyildiz Jan 25 '23 at 12:42

1 Answers1

-2

One advantage of a Spring Boot executable jar is that it contains all of your application's code as well as its dependencies. This gives you a single unit that you can deploy. When you're packaging your application in a container, it becomes this single unit of deployment with the added benefit that it also contains the JVM and anything else your application needs. Given that the container is a single unit of deployment, the jar packaging arguably isn't needed any more.

As described in the Spring Boot reference documentation, unpacking the executable jar when building the container can result in a slight improvement in startup time. You can explode the jar file and then use Spring Boot's JarLauncher to launch the exploded "jar":

$ jar -xf myapp.jar
$ java org.springframework.boot.loader.JarLauncher

This approach ensures that the classpath has the same order as it would have when running the application using java -jar.

Alternatively, you can specify the classpath manually and run the application's main method directly:

$ jar -xf myapp.jar
$ java -cp BOOT-INF/classes:BOOT-INF/lib/* com.example.MyApplication

This will result in a further small boost in startup time at the cost of potentially changing the order of the classpath.

Andy Wilkinson
  • 108,729
  • 24
  • 257
  • 242