Fork me on GitHub

When I use leiningen to build an uberjar, it will compile each of my namespaces and when it gets to where I use core.cache, it will fail with

Syntax error compiling at (clojure/core/cache/wrapped.clj:53:25).
Syntax error compiling at (clojure/core/cache/wrapped.clj:53:25).
No such var: c/through-cache
Earlier I had some dependencies issues leading leiningen to use both core.cache 0.8.2 and 0.6.5, and the latter is missing through-cache. After experimenting with exclusions, I managed to stop leiningen from downloading version 0.6.5. Right now I only get 0.8.2 in my .m2 folder, and I have also cleaned my entire project directory, so there should be no target/classes leftover; just source code. Still I'm getting the same error everytime. Is there something I've missed?


> dependencies issues leading leiningen to use both core.cache 0.8.2 and 0.6.5 a bad dep might bring in a duplicate lib because it precompiled, but lein never puts the same lib on the classpath twice


I think your real issue is that it's not using the version you want, check out the output of lein deps :tree


that will show conflicts in dep versions, and which versions it's picking, and why


There’s also “lein deps :plugin-tree” in case you have plugins brining in dependencies


@regen oops, forgot to tag you above


I checked lein deps :tree and oddly core.cache showed up only once for 0.8.2, which was the direct dependency.


I tried plugin-tree as well, and it doesn't pop up there.


Before this I had a very confusing problem where [yogthos/config "1.1.7"] was a direct dependency, and then I had another dependency which had [yogthos/config "0.9"] as a direct dependency. When I built the uberjar, it would use version 0.9.


I cannot make sense of why that would happen. It's supposed to use the version closest to root right?


I make sure to clean all the leiningen dirs so only the source code remains in the project directory, but I'm still paranoid there's some cache I'm missing. I've also tried clearing .m2 but it will still download both those versions.


here's a thing you can try: use io/resource to see if the ns is pulled from an unexpected place:

user=> ( "clojure/core.clj")
#object[ 0x7b02e036 "jar:file:/home/justin/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar!/clojure/core.clj"]


there's a similar trick for checking if it came from a precompiled init...


user=> ( "clojure/core_init.class")


or you can look at classpath and check for weird entries

user=> (System/getProperty "java.class.path")


Thanks. I'll give that a try for "clojure/core/cache/wrapped.clj" once I've changed the source code to make it run.


you can also start a repl from an uberjar, even if your own code in your jar is broken:

$ java -cp target/foo-0.1.0-SNAPSHOT-standalone.jar clojure.main -e '( "clojure/core.clj")'
#object[ 0x28d6290 "jar:file:/home/justin/foo/target/foo-0.1.0-SNAPSHOT-standalone.jar!/clojure/core.clj"]


Wow. Some wizardry in here!


and similarly for the classpath lein builds by default:

$ java -cp $(lein cp) clojure.main -e '( "clojure/core.clj")'
#object[ 0x4e517165 "jar:file:/home/justin/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar!/clojure/core.clj"]


@regen I learn well from pain, and the times I've had to care about these things have often been painful


Damn. I guess it's time for me to go through the pain as well...


the nice thing is that clojure is full of a bunch of great tools that can tell you what's wrong with a clojure codebase / built artifact


the C or even Java equivalents of this debugging are much weirder


I can't spot anything immediately wrong, but I'll try again with these newfound tools tomorrow as it's close to midnight here.