Investigate fat jar unpack options

[philwebb]

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

[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.

[philwebb]

We think layertools should cover unpack needs for most users.

[nngo]

@philwebb can you provide a link to layertools with instructions on how it covers the unpack needs?

[wilkinsona]

There's some information in the reference documentation.

[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