Clojurians Log v2
tools-build
I'm stumped on a strange uberjar error and hoping someone can provide some insight. Its a Polylith workspace, and we recently updated one of our base namespaces to cleanup some polylith warnings; from workspace/bases/microservice/src/clj/microservice/core.clj to workspace/bases/microservice/src/clj/qualifier/microservice/core.clj. Very minimal change throughout that one base thats being built into the uberjar for this project. Standard way of running for dev, clj -M:run still works great, and building the uberjar seems to work fine, but attempting to run the uberjar throws a ClassNotFoundException for clojure.tools.reader.
Exception in thread "main" java.lang.NoClassDefFoundError: clojure/tools/reader/reader_types$source_logging_push_back_reader
at hugsql.parser$parse.invokeStatic(parser.clj:261)
at hugsql.core$parsed_defs_from_file.invokeStatic(core.clj:44)
at hugsql.core$def_db_fns.invokeStatic(core.clj:530)
at hugsql.core$def_db_fns.invoke(core.clj:530)
....
Caused by: java.lang.ClassNotFoundException: clojure.tools.reader.reader_types$source_logging_push_back_reader
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
...
did you update any dependency versions at the same time you made the change?
is there a clojure/tools/reader/reader_types$source_logging_push_back_reader.class in the uberjar file?
do you use core.async anywhere?
what options are you passing to compile-clj?
are you using :ns-compile with a single main namespace?
my guess is renaming the namespace changed the order in which namespaces are being aot compiled, which changes the load order, and for some reason now clojure.tools.reader.reader-types is being loaded before/outside the context of aot compilation, so it is not being aot compiled, so the class files are missing when you go to run from the uberjar
no dependency version changes in between. the reader_types.clj exists in the jar, but no class file (which is the problem).
we do have core.async in the base, included as a dep, but its not acutally being used
im using almost exactly the polylith build.clj https://github.com/polyfy/polylith/blob/master/build.clj
the latest version of core.async does problematic stuff with code loading, but I don't think when that issue is triggered it looks like this
and shouldn't be an issue if it is never used (maybe if a dep uses it?)
your guess sounds very right. let me go look at the aot compile stuff and maybe see what could be causing it. because youre right, the clj is there, its just not compiled into a class file
a common source for libraries getting loaded before they are supposed to is having a user.clj around that is loading them
yeah the :aot alias does match the updated namespace. the corfield build uber task is doing the compile and bundle together i believe
oh my god, got it
it needed a :transitive true in the opts being passed to the uber task
sean mentions it at the bottom of the build-clj readme for monorepos, but we somehow had it working without it previously, and this namespace change just exposed it with this odd error
Yeah, that sort of "knobs and dials" issue is why I've sunsetted build-clj and I recommend people use tools.build directly instead.
indeed, i ended up at the polylith recommended build.clj trying to migrate off of build-clj, but then realized its still being used in that polylith build file! Going to go through and update the build-clj/uber calls and others to use tools.build instead. Looking forward to an updated recommended polylith build.clj tho eventually!
Can you pop into #polylith and grumble about it? I'm about headed out the door and I'm not even sure if there's a GH issue for it right now.
will do! Appreciate it