Yes, this is reported in issue https://github.com/polyfy/polylith/issues/304 and https://github.com/polyfy/polylith/issues/312 and will be included in the next release that I'm working on.

Apologies for the delay. I explain what happened with our uberjar build in more detail on the tools.build channel post. All we did was change a namespace across one of our polylith bases, and that caused the uberjar builds that used it to break. Throwing very odd class-not-found exceptions on clojure.tools.reader types that were definitely there. No dependencies changes or anything else, just added a namespace qualifier . It seemed like it somehow threw off the aot compile for dependencies or something, as the clj file made it into the uberjar, but not the compiled class file (of the dep that was erroring). Something about transitive true helped it pick up and compile all the necessary dependencies correctly, but was also working before without it before the namespace change. Very odd all around.

Sounds more like a cached dependencies issue that -Sforce should fix -- or removing the .cpcache folder in the directory where you run the CLI...?

:transitive should have no effective at all on uberjars (and in fact should not be used for uberjars). That's why I suspect it was a stale cache -- adding :transitive true would change the classpath which would force the cache to be updated.

Anyways, glad you "solved" it. The poly project no longer uses build-clj on master and the docs will be updated soon.

Appreciate the info! I'll takeout the transitive true and try a -Sforce clean and maybe toss cpcache too and see. Very well could just be the case! Thank you for updating the poly proj build.clj as well! 👍