@U09R86PA4 I've been working on a tool for creating docker images that uses the lib directory of jars approach (https://github.com/atomisthq/jibbit). I think of this as the approach that I first saw with https://github.com/orb/lein-metajar where all the jars were unpackaged, and then a ClassPath manifest was created. I did something similar to what Alex Miller mentioned: https://github.com/atomisthq/jibbit/blob/main/src/jibbit/core.clj#L85-L114

Iterate over the :classpath-roots in the basis to copy the files, and also to produce the Class-Path manifest entry.

I keep the libs and aot compiled parts on separate layers because the libs tend to change at a slower rate, and I can often cache that layer for quite a while.

@U0143KP47M4 thank you. My goals are along the same lines, not for docker per se but for smaller cacheable units for faster builds and deploys, and possibly also sharing aot-ed code for faster local dev startup. Also I’ve hit many edge cases related to uberjarring (resource merging, sealing, multi-release jars, etc) and I am just done fighting that.

Ya, the resource-merging problem had been a real headache for me too. Thanks for bringing up the multi-release and sealed jar issues too. I hadn't considered those cases but that's really interesting.