Potential future issue with uberjar creation

[jeroenvandijk]

I guess mostly for reference:

At work I've gained more experience with uberjar creation using boot-clj and boot-tools-deps. I've ran into a situation where it doesn't work properly, namely when you don't aot all namespaces. If you want to use a namespace from a tools.deps dependency (i.e. git) this can fail when this namespace is not (aot-ed) as it will not be included in the jar.

Right now, all namespaces are aot-ed so everything is fine. If you want to change this though, it's probably better to switch to something like juxt/pack

[dundalek]

Thanks for the heads up. Can you think of a case when we wouldn't want to AOT all namespaces?

[jeroenvandijk]

Good question, not sure actually. When Closh would be used as a dependency to something else and there are conflicts in the dependencies AOT might give issues (e.g. clojure version), but I'm not sure if this would ever happen.

[dundalek]

From my understanding libraries are desirable to include non-AOT-ed sources to prevent possible conflicts as you mention. If anyone wanted to use closh as a dependency they could include it as git dep and which would build it from sources. But for the final binary it should probably be fine.

But having a leaner build tool that works directly on top of tools.deps is appealing to me for the sake of simplicity. Maybe some time in the future..

[dundalek]

Another potential tool to use: https://github.com/tonsky/uberdeps

[dundalek]

Another one: https://github.com/seancorfield/depstar

[dundalek]

And another one: https://github.com/EwenG/badigeon https://cjohansen.no/clojure-in-production-tools-deps/