There's always going to be a certain overhead with our fat jar format so we should investigate what works best in terms of running an unpacked jar. This might overlap a little with #12545.
We should consider:
- Do users want a zip from the build, or do they want to convert a fat jar
- What happens with the embedded startup scripts
- How does it effect PaaS and K8S deployments
- How do we not overwhelm users with too much choice
Comment From: vpavic
Couldn't we have the task that builds the fat jar split in two stages - one that prepares fat jar contents in the build work directory, and other that does the actual assembly?
That way if someone wants to package the application into a Docker image, or something else, they'd need to simply run the prepare task. That seems much more optimal than unpacking.
I should note that these days I mostly use Jib, so I don't have a pressing need for this, but for some advanced scenario I'd still have interest in such arrangement.
Comment From: philwebb
We think layertools should cover unpack needs for most users.
Comment From: nngo
@philwebb can you provide a link to layertools with instructions on how it covers the unpack needs?
Comment From: wilkinsona
There's some information in the reference documentation.
Comment From: nngo
@wilkinsona Thanks for pointing to the new "Building Docker Image" section 31 added to the 2.3.x milestone reference docs > Spring Boot Features > Building Docker Images > Layering Docker Images. I also just found this Creating Docker images with Spring Boot 2.3.0.M1 blog post on Jan 27, 2020 by @philwebb : https://spring.io/blog/2020/01/27/creating-docker-images-with-spring-boot-2-3-0-m1