Fork me on GitHub

Can anyone point me to some build tools in the tools.deps.edn ecosystem that prepares “lib directory of jars”-style deployment artifacts instead of an uberjar?


@U09R86PA4 I've been working on a tool for creating docker images that uses the lib directory of jars approach ( I think of this as the approach that I first saw with where all the jars were unpackaged, and then a ClassPath manifest was created. I did something similar to what Alex Miller mentioned:


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.

👍 1

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.