This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-07-12
Channels
- # announcements (2)
- # babashka (22)
- # babashka-sci-dev (15)
- # beginners (62)
- # calva (2)
- # cider (8)
- # clj-kondo (33)
- # clojure (52)
- # clojure-europe (46)
- # clojure-losangeles (1)
- # clojure-norway (5)
- # clojure-spec (7)
- # clojurescript (31)
- # conjure (20)
- # data-science (4)
- # datalevin (16)
- # fulcro (28)
- # hyperfiddle (71)
- # introduce-yourself (3)
- # lsp (50)
- # off-topic (16)
- # polylith (8)
- # portal (3)
- # practicalli (1)
- # reitit (1)
- # releases (2)
- # tools-build (22)
- # vim (8)
- # xtdb (17)
Any plans for an updated polylith build.clj file now that Sean's build-clj has been deprecated? Just resolved a nasty bug in our uberjar build using the polylith build.clj that was caused by a missing :transitive true for dependency resolution in build-clj.
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.
@apaine13 The :transitive
option in build-clj
is intended for building library JAR files, not uberjars. Can you explain how/why your uberjar process broke?
At work, we build uberjars via tools.build
and we do not need anything equivalent to the "lifted basis" stuff from build-clj
.
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! 👍
@apaine13 The :transitive
option in build-clj
is intended for building library JAR files, not uberjars. Can you explain how/why your uberjar process broke?
At work, we build uberjars via tools.build
and we do not need anything equivalent to the "lifted basis" stuff from build-clj
.