tools-build

2025-07-29T21:32:30.400679Z

with tools build, we can add a version to the jar when building it, but is there a recommended way to go about pulling that version from the (uber)jar file that is being run? I would like to track versions via the jar's pom.xml vs trying to keep things in sync with version tags and ensure the version is set from the tags via an environment variable or other mechanism. Main example usage would be add the running jar's version to log context, as well as system history events/metadata (e.g. this was done by version x.y.z)

Alex Miller (Clojure team) 2025-07-29T21:35:56.240069Z

you could create a resource (text file) in the jar with the version string. This is, for example, how Clojure's *clojure-version* works - the build creates a file clojure/version.properties which is read when clojure.core is loaded and then parsed into data returned by *clojure-version*

Alex Miller (Clojure team) 2025-07-29T21:36:37.076189Z

strongly recommended not to pollute the top-level with the resource, put it in a subdir that you "control" like your code

Alex Miller (Clojure team) 2025-07-29T21:37:37.636439Z

from a tools.build perspective, this is just spit of the version to the resource in the directory you are jarring from

2025-07-29T21:43:10.006709Z

Yeah, I had thought of something like a spit to an EDN file, but wanted to check if there were any general conventions around app version availability from both a larger community and operational interoperability perspectives.

favila 2025-07-29T21:58:08.823379Z

maven will put a pom.xml at META-INF/maven/{groupId}/{artifactId}/pom.xml Leiningen will add a simpler pom.properties file version with a version= entry. See "how do I determine my project's version at runtime?" in the https://leiningen.org/faq.html. These are the conventions for this sort of thing that I am aware of

Alex Miller (Clojure team) 2025-07-29T23:16:52.129049Z

I wouldn’t rely on that personally in case you change your build process