Fork me on GitHub
#babashka-sci-dev
<
2022-09-30
>
cap10morgan20:09:40

I think I have a viable pod library approach that avoids the classpath scan. Just getting the details sorted out now. It relies on putting the pod-manifest.edn inside a directory (in the library JAR or local root path) that matches the munged top-level namespace element (e.g. pod-fluree-crypto.crypto -> pod_fluree_crypto/pod-manifest.edn). That way the required namespace can be mapped to a specific resource path in the classpath.

borkdude21:09:51

how does that avoid a scan? you still need to open jar files?

borkdude21:09:42

(this might not be a big problem, just curious)

cap10morgan21:09:47

it loads them the say way any other :deps library gets loaded via source-for-namespace

cap10morgan21:09:59

the extent to which that's a scan I guess depends on the loader it's passing to getResource, which I haven't looked into too much yet. but it seems to work very quickly compared to my previous classpath scanning code FWIW

borkdude21:09:40

I think you would get similar performance for nested dirs, you don't have to use a 1 level directory for this. https://clojurians.slack.com/archives/C02FBBU61A9/p1663788790758779

borkdude21:09:52

so next to .bb , .clj and .cljc there would be a fourth extension which contains a file that points to the pod manifest