1. They try to load the library from the system if possible. 2. Failing that, they extract the library included in the jar to a temporary location and try to load this.
This, I believe, is the best pathway although it is somewhat outside the purview of tools.deps; perhaps there could be a companion library?
Currently tools.deps does not support jars that package their own native libraries.
chrisn@chrisn-dt:~/dev/tvm-clj/tvm/build$ clojure -Sdeps '{:deps {techascent/tech.opencv {:mvn/version "1.2"}}}'
Clojure 1.9.0
user=> (require '[tech.opencv :as opencv])
WARNING: cast already refers to: #'clojure.core/cast in namespace: tech.datatype.base, being replaced by: #'tech.datatype.base/cast
WARNING: cast already refers to: #'clojure.core/cast in namespace: tech.datatype, being replaced by: #'tech.datatype/cast
CompilerException java.lang.ClassNotFoundException: org.bytedeco.javacpp.opencv_core, compilingtech/opencv.clj:1:1)
A form of this works from leiningen and java.
Here is a good chunk of the leiningen code to do this:
https://github.com/technomancy/leiningen/blob/master/leiningen-core/src/leiningen/core/classpath.clj
A lot of java software does this:
1. They try to load the library from the system if possible.
2. Failing that, they extract the library included in the jar to a temporary location and try to load this.
This, I believe, is the best pathway although it is somewhat outside the purview of tools.deps; perhaps there could be a companion library?