This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-14
Channels
- # aleph (1)
- # aws (3)
- # beginners (75)
- # boot (1)
- # bristol-clojurians (2)
- # clj-kondo (18)
- # cljs-dev (5)
- # cljsrn (10)
- # clojure (62)
- # clojure-dev (15)
- # clojure-europe (3)
- # clojure-india (2)
- # clojure-italy (9)
- # clojure-madison (1)
- # clojure-nl (9)
- # clojure-norway (9)
- # clojure-spec (11)
- # clojure-uk (206)
- # clojurescript (30)
- # copenhagen-clojurians (1)
- # data-science (1)
- # datascript (2)
- # datomic (27)
- # emacs (1)
- # events (1)
- # fulcro (12)
- # gorilla (1)
- # jobs (2)
- # kaocha (2)
- # leiningen (4)
- # lumo (7)
- # malli (1)
- # off-topic (2)
- # pathom (14)
- # pedestal (5)
- # quil (3)
- # re-frame (8)
- # reitit (3)
- # remote-jobs (16)
- # ring-swagger (1)
- # shadow-cljs (70)
- # tools-deps (7)
- # vim (5)
- # vrac (1)
Hey all! I'm consuming a library that seems to have packaged itself as an uberjar including all of its dependencies. I also depend on one of the libraries it uses and it looks like that it's overwriting the requires to an old version (which requires a java class that isn't packaged in the new one). Is there any way for me to force my project to use the new version instead of what it's using?
I'm not super familiar with the internals of how this all works, so if the above diagnosis is complete nonsense, please excuse me!
makes total sense
and no, not easily
you should tell that lib to stop doing that :)
the effect you need is to force your lib version earlier in the classpath ordering. tools.deps mostly does not provide support for explicit ordering
I possibly could come up with a hacky workaround, but it would be a hack. the real solution is the lib