Fork me on GitHub

Say, are there options available for customizing the groupId, version, etc in pom.xml during the course of clojure -Spom?


@timgilbert update the generated pom.xml, then -Spom won't override them.


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 lein-v does


I imagine you're into "write another tool" territory 🙂


If someone writes a manifest generator, let me know 😉 I’m on the hunt for one.


@arrdem I forked depstar and added basic manifest generation -- then decided I really didn't need it and removed it.


I’m somewhat surprised how far bare jars have gotten me so far - we’ll see.


I'm surprised by all the git deps users wanting to have artifacts back


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.


I get it from a transition strategy or reach perspective


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?


(Links welcome, no need to type it out here)


I finally got that Pom.xml is a maven thing :)


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 Check out pack's skinny jar mode 🙂


@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.


Oh, can you share that new relic thing please?


@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.

seancorfield16:11:49 -- this covers how to add Trace annotations to Clojure functions for use with New Relic.


Happy to answer any other specific Qs you might have.


Right, that! Thanks so much!