add support for "layered JARs" for Spring Boot 2.3 projects

[62mkv]

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.

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.

[bparees]

Is there something s2i itself can take advantage of here, or is this just something that a particular s2i-java builder implementation (via its assemble/run scripts) would leverage?

[62mkv]

if this is a question to me, then honestly I have no idea, who or how will benefit of this. I can only say that as an OpenShift and SpringBoot user I would want to be able to use this feature. And I would assume that RedHat or whoever is behind OpenShift, should be interested in giving their users useful features. Where am I wrong here?

[bparees]

@62mkv yes it was a question for you. Since you brought up the feature, i'm trying to understand how you would like to see s2i take advantage of it. My impression is that it is not something s2i itself (the tooling binary) can directly leverage, and that if an s2i builder image wanted to take advantage of it, it could do so without changes to the s2i binary itself (by providing an appropriate run/assemble script that leveraged this additional metadata).

this isn't about whether you're "wrong" here, this is about me trying to understand if there's actually a change that can/should be made in s2i to take advantage of this, or if this is a suggestion that should be directed specifically to the authors of s2i-java builder images, in which case I would close this issue and reopen it against one of our s2i-java builder repos.

[62mkv]

well, I have been sent here from s2i-java repository. so I assumed it's either this (upstream) or them that should take that into consideration. see here fabric8io-images/s2i#249

@rhuss said they don't believe how s2i-java might possibly implement it.. hence I've created this issue here

[bparees]

ok, I understand now. Unfortunately it is unlikely s2i can take advantage of this. S2I is fundamentally built around the idea of a single layer on top of a base image which inherently goes against the idea of layered jars.

The best you can do to take advantage of it would be to have an s2i-java builder image that makes use of the incremental/save-artifacts flow to extract the unchanging deps from the previous build/layered-jar and inject them into the subsequent image to potentially avoid repulling/building them during the assemble phase. Which you can do today, butt would be something the s2i-java builder image would implement.

But I don't see that we'd introduce a concept of explicit layer construction in s2i itself to support layered jars for springboot explicitly, it just fundamentally doesn't align with how s2i works when constructing images.

[62mkv]

Hi!

in which case I would close this issue and reopen it against one of our s2i-java builder repos.

is that the way to progress then, @bparees ?

[bparees]

I want to be clear i haven't thought fully through how a save-artifacts/assemble script would take advantage of these "layers" so i'm not 100% certain that an s2i-java builder can do something useful with this, but I don't see that the source-to-image project itself can do anything to leverage the feature. So yes, i think discussing how an s2i-java builder image could take advantage of layered jars, within the s2i-java repo, makes more sense than discussing it here. I'm happy to help participate in the discussion around save-artifacts/assemble there.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.