This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # beginners (97)
- # boot (3)
- # cider (23)
- # clara (9)
- # cljs-dev (40)
- # cljsrn (6)
- # clojure (107)
- # clojure-finland (2)
- # clojure-india (3)
- # clojure-italy (15)
- # clojure-nl (2)
- # clojure-spec (107)
- # clojure-uk (91)
- # clojurescript (28)
- # cursive (10)
- # data-science (4)
- # datomic (26)
- # duct (1)
- # emacs (6)
- # events (9)
- # figwheel-main (4)
- # fulcro (4)
- # graphql (2)
- # jobs (3)
- # jobs-discuss (12)
- # juxt (7)
- # kaocha (6)
- # off-topic (8)
- # onyx (2)
- # parinfer (13)
- # pedestal (32)
- # portkey (1)
- # re-frame (58)
- # reagent (17)
- # reitit (21)
- # ring-swagger (3)
- # shadow-cljs (35)
- # spacemacs (1)
- # tools-deps (33)
- # yada (13)
Say, are there options available for customizing the groupId, version, etc in pom.xml during the course of
Hrm. I don't love having half-generated code in my codebase that I'll need to create another git commit for whenever I update deps.edn
I suppose I could write a tool that would run
-Spom and then update the relevant values. What I'm actually looking for is something that will create the version number based on git tags on my repo in the same way
@arrdem I forked depstar and added basic manifest generation -- then decided I really didn't need it and removed it.
We build/deploy bare uber JARs and run them that way in production. No AOT.
java -cp path/to/the.jar clojure.main -m entry.point
At this point I’m convinced that between Katamari / git deps I’ll probably only use external libraries from Maven again. Which is great. But I have internal users who aren’t on that workflow yet and who I want to be able to deploy artifacts with manifests and poms for.
making nicer / faster psuedo-uberjars in docker is easy enough, doesn’t require any of this and that’s my only deployment need.
Can someone share some knowledge about the difference between bare jars and Uberjars and what manifests are for?
I’d love to be able to just rsync individual jars instead of an Uber jar, then somehow launch my app with the correct classpath. I guess if you have clj command line on the server installed, you can do that but you pay for the startup compilation time.
@orestis FYI, we deploy source uberjars to production -- no AOT -- and with all their dependencies included, they're still only 20-30MB so it's a pretty small payload to upload across servers (but, yes, would take a while to upload from a dev machine I guess).
I tried AOT jars and they still are roughly 30-40MB so still pretty small. It’s the compiling that takes time :)
And it’s annoying that you compile the same dependencies over and over. I’m fairly sure I’ve seen Alex & co discussing this as a potential improvement in the future.
Yes, I saw this the other day on the clojure mailinglist and was excited by it too. It’s a mild annoyance that uberjaring and AOTing a moderately sized app takes 2 minutes. I understand why @U04V70XH6 likes to avoid AOTing apps; I’m assuming to have quicker builds… and I’ve been contemplating only AOTing nightlies, to bring CI times down… but still have uberjars start quickly. I think this problem could be solved if we could easily AOT libraries. I can’t recall what the issues are here; I suspect it’s to do with how clojure.core/compilation/read/eval get linked in to libraries.
One big problem with AOT for libraries is that they can locked into specific versions of Clojure (this was a problem back in the day when some did compile their libraries for distribution).
With source-only libraries they should always work with all future versions of Clojure.
AOTing an application is safe because it's an entire system. Self-contained. For us, the startup time hit just isn't worth adding an AOT step. New Relic's instrumentation at startup is a much bigger overhead for us than Clojure's compilation.
@orestis What do you mean? We just use the regular Java agent for New Relic. I think we had to blacklist a particular classloader in Clojure to avoid prohibitively slow NR startup, but otherwise you just add the JVM startup options to point at their library and config file.
http://corfield.org/blog/2016/07/29/clojure-new-relic-slow-startup/ -- talks about the slow startup issue.
http://corfield.org/blog/2013/05/01/instrumenting-clojure-for-new-relic-monitoring/ -- this covers how to add
Trace annotations to Clojure functions for use with New Relic.