-
Notifications
You must be signed in to change notification settings - Fork 84
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
Comments
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 |
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 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 .... |
Just to clarify that it's not so much about speeding up the build as about saving space in the imagestream repo and re-using layers as much as possible
--
Sent from Mail.ru app for Android Wednesday, 20 May 2020, 09:03AM +03:00 from Roland Huß notifications@github.com :
…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 ....
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub , or unsubscribe .
|
@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 :) |
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. |
ok, I've raised that now: openshift/source-to-image#1039 |
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..) |
Hi, I’m also very interested about this feature. |
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 requestThe text was updated successfully, but these errors were encountered: