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.

heh

yagni

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.