This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-05-01
Channels
- # aws (1)
- # beginners (237)
- # boot (2)
- # calva (6)
- # cider (16)
- # clara (10)
- # clj-kondo (1)
- # cljs-dev (24)
- # clojure (29)
- # clojure-brasil (2)
- # clojure-dev (20)
- # clojure-europe (1)
- # clojure-italy (56)
- # clojure-japan (1)
- # clojure-nl (16)
- # clojure-spec (12)
- # clojure-uk (12)
- # clojurescript (24)
- # clojureverse-ops (3)
- # core-async (3)
- # cursive (21)
- # datascript (5)
- # datomic (82)
- # devops (5)
- # duct (14)
- # emacs (2)
- # fulcro (2)
- # jobs (6)
- # juxt (7)
- # kaocha (6)
- # leiningen (19)
- # luminus (3)
- # nrepl (51)
- # off-topic (208)
- # other-languages (1)
- # re-frame (8)
- # reagent (9)
- # remote-jobs (6)
- # shadow-cljs (37)
- # spacemacs (6)
- # testing (12)
- # tools-deps (25)
deps.edn
newbie here: Anyone's got some intelligent input to the following issue, where a working lein
based project, using a java library hosted on jitpack
, doesn't work when used via deps.edn
(dependency tree doesn't get resolved)?
https://github.com/luposlip/json-schema/issues/1
even when it's already referred to by the json-schema
library?
The user wants to use json-schema
, which already refers to jitpack, from a project using deps.edn
.
Hmm.. When a library is packaged and deployed to clojars it normally works out of the box when using it from another lein project, regardless of the dependencies and where they are stored.
If this is not the case with clj
+ deps.edn
it seems like a showstopper to me.
hey, moving from boot to tools-deps + kaocha, which of the many uberjar building tools do you recommend to replace boot鈥檚 capabilities? I see several but see no consensus from the community on which is the most stable / can expect future maintenance.
We've been using https://github.com/seancorfield/depstar in production for several months now. Does the job.
thanks, but I just noticed that it doesn鈥檛 do AOT, guess I鈥檒l need to add that to the list of required features so that the build tooling change does not change the produced artifact
We stopped AOT'ing long before that 馃檪 Hence depstar
does exactly as much as we need: build a JAR from the classpath. In production we do java -cp /path/to/the.jar clojure.main -m our.entry.point
What is the current reason to consider AOT evil? We鈥檝e just started using it for our service uberjars to shave a modest but meaningful time off of startup time.
If you're using it as the very last stage, to produce an uberjar, and you really need it to improve startup time, that's "fine". But the Leiningen default where the main namespace is :gen-class
'd and AOT is the default in project.clj
just gets beginnners into a mess -- and it is completely unnecessary. AOT overall is completely unnecessary -- unless you really, really care about startup time for a final production artifact.
AOT's transitive compilation issues and the problems you can run into when you end up with a mix of .class
and .clj
versions of the same file can be hell to debug. Much better to just avoid all of that, unless you know what you're doing and you see AOT as purely an end-of-the-line optimization.
The biggest overhead for us at startup time is New Relic's Java agent instrumenting classes (since Clojure generates so many).
And since nearly all of our processes are long-running, we just don't care about startup time.
I could see it mattering more if you need to scale your service quickly due to large demand spikes.
In the end I took your advice and did not AOT before uberjaring. Still I stayed with badigeon
because it allowed me to exclude some cljs related files I don鈥檛 need from my resources, which sadly depstar
doesn鈥檛 support, having a static exclude function.
Feel free to create an issue for depstar
to exclude files -- I just refactored some of that code recently so it'll be easier to extend to support options (although, right now, depstar
has no command-line options at all beyond the JAR filename).