Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for layered JARs introduced in Spring Boot 2.3.0 #249

Open
62mkv opened this issue May 19, 2020 · 8 comments
Open

add support for layered JARs introduced in Spring Boot 2.3.0 #249

62mkv opened this issue May 19, 2020 · 8 comments

Comments

@62mkv
Copy link

62mkv commented May 19, 2020

I am not sure if this is feasible or even is this the right project to raise this issue. but from what I understood thus far, it should be possible to get at least a hint.

Anyway, Spring Boot as of version 2.3.0 introduced concept of "layered JARs" (https://spring.io/blog/2020/01/27/creating-docker-images-with-spring-boot-2-3-0-m1#layered-jars) and this seems to be very relevant to s2i-java build flow on the OpenShift.

From the docs and repository history, I don't have an impression that this is already supported by s2i-java, hence this feature request

@scottfrederick
Copy link

The format of the Spring Boot layers index file can be seen here: https://docs.spring.io/spring-boot/docs/2.3.0.RELEASE/reference/htmlsingle/#executable-jar-war-index-files-layers

When layer information is provided there will be an entry Spring-Boot-Layers-Index: BOOT-INF/layers.idx in the jar META-INF/MANIFEST.MF manifest giving the location of the file.

@rhuss
Copy link
Contributor

rhuss commented May 20, 2020

You are right, layered Jars are not directly supported by this image, but I wonder how an s2i build on openshift could benefit from it, as the s2i scripts don't really have an influence on the image layering. If you are leveraging the s2i incremental build, then some content from the former image can be copied over to the actual build. For now this is just the local maven repository from ~/.m2/repository. Of course the lib and resource layer from the dependencies could be copied over, too, but would this considerably speed up the build ? (as I expect those dependencies to be in the also-copied local Maven repository, so it would be "just" a local copy).

One could benefit from the layered approach when one has a more fine granular way of defining the layer of a container image (like directly with a Dockerfile), I don't see how this could be achieved with the S2I build mechanism.

But maybe I overlooked something ....

@62mkv
Copy link
Author

62mkv commented May 20, 2020 via email

@rhuss
Copy link
Contributor

rhuss commented May 20, 2020

@62mkv got it, but I still not see how we can translate the layered jars to container image layers using s2i. 'would be happy if I'm wrong :)

@62mkv
Copy link
Author

62mkv commented May 21, 2020

is there any extended documentation on "how s2i-java" works? I've seen the build process ended up defining around 26-28 layers, some as small as several bytes long, but the last one (the one with the fat JAR, I assume) is like 400Mb. if I figured out how those layers are defined, maybe it would be more clear, where to raise this issue.

@62mkv
Copy link
Author

62mkv commented May 21, 2020

ok, I've raised that now: openshift/source-to-image#1039

@62mkv
Copy link
Author

62mkv commented May 28, 2020

that one (openshift/source-to-image#1039) has come to a stalemate. They say either it's s2i-java that does the trick, or it cannot be completed at all. May I ask @rhuss to look into that and if that's correct, then probably this could be closed (alas..)

@ljuaneda
Copy link

ljuaneda commented Oct 1, 2021

Hi, I’m also very interested about this feature.
at my company we use s2i build from binary and I’m thinking of implementing a save-artifact and assemble script that should be able to do incremental build with layered jars.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants