GoogleContainerTools
Spring Boot use case: using `spring-boot-loader` and classpath jar order
Thank you @chanseokoh for this thorough and well written explanation ! You've made clear, precise and wise points that have changed my mind :).
We are using Jib with Spring Boot (and JLink, but that's another topic) and are very happy with it. Please continue the good work.
As you say at one point it might be useful to have this kind of capability. One case where I think it might be useful is when defining our own entrypoint. When that happens we need to define ourself the java execution command, something like
# Retrieve the files present in the /app/libs directory before subsequently joining them with a ':'
LIBS=/app/libs/*
exec java ${JAVA_OPTS} -cp /app/resources:/app/classes:${LIBS/ /:} ${MAIN_CLASS}
In that case I think the spring-boot-loader might do a better job than us, since it will handle the classpath and the main class for us.
Also, although I'm not sure if it's significant, Spring Boot now creates a classpath.idx file providing the ordering that jars should follow when added to the classpath. At one point it might be a good idea to follow what is written in that file.
Originally posted by @celcius112 in https://github.com/GoogleContainerTools/jib-extensions/pull/31#issuecomment-655584059
I imagine that if we were to support this, we'd go with an extension. (Part of the reason is explained in https://github.com/GoogleContainerTools/jib-extensions/pull/31#issuecomment-655553254).
We are using Jib with Spring Boot (and JLink, but that's another topic)
@celcius112 unrelated to this issue, but we are very interested in making Jib work with JLink at this stage. I tried Jib on a JLink project (set up with Maven JLink plugin) a long time ago, and I remember I made it work with some workarounds and hacks. Other than that, we've not heard anything related to JLink from users. If you have an issue using Jib with JLink or any feedback, feel free to open a new issue.
# Retrieve the files present in the /app/libs directory before subsequently joining them with a ':' LIBS=/app/libs/* exec java ${JAVA_OPTS} -cp /app/resources:/app/classes:${LIBS/ /:} ${MAIN_CLASS}
I'm just curious. Why do you expand file paths in /app/libs using a shell? If you pass the literal * (without expanded by a shell), then JVM will expand it internally (will match *.jar files only).
And also we've heard a potential risk when listing all the dependencies on the command line, as some OSes may have a relatively short limit on command length (although I think in practice it's very rare to hit this issue unless you have hundreds of dependencies rooted deep in paths).
I'm just curious. Why do you expand file paths in /app/libs using a shell ?
Because we didn't know this feature existed in the JDK 😅 We shall read the classpath documentation a bit more carefully in the future (we rarely needed to until now), thanks for bringing that up.
If you have an issue using Jib with JLink or any feedback
No particular issues except some customization using JibExtension and a few custom gradle tasks. The difficult part was that we wanted to dynamically find the required modules for our non-modular application. To do that we apply the jdeps command on every dependencies as well as the source files. With the list of required modules we then have a gradle task to generate our custom JRE with jlink, and thanks to the recent resolution of https://github.com/GoogleContainerTools/jib/issues/1581 we can easily include it in an extra layer under the path we expect it to be. With the help of kotlin's coroutines and gradle's cache it takes at most 15sec (with a medium size application) and at least 1sec.
There are a few small details here and there, but for the most part and our project it works like a charm for now.
@chanseokoh Should we file this issue in https://github.com/GoogleContainerTools/jib-extensions instead? Or do the existing Spring Boot extensions address this usecase?
The existing Spring Boot extension doesn't do anything about this issue. It is not unreasonable to special-case Spring Boot with an extension, so you can move this issue to jib-extensions if you want. However, we did commit to provide good experience for Spring Boot given the prevalence and importance of it, so currently we do have some special-case handling for Spring Boot.
BTW, because classpath JAR ordering is stable for Java 9+ and it's now easy to extract Jib-computed classpath and main class, I think they are no longer a big deal in that aspect. What remains is about using spring-boot-loader, but I'm not sure how much value it'd provide. Maybe an extension is still a better approach.
I'll keep it here, but with the note that this should be implemented as an extension.