This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-11-04
Channels
- # announcements (5)
- # babashka (2)
- # beginners (53)
- # biff (11)
- # calva (5)
- # cider (4)
- # clojure (32)
- # clojure-austin (2)
- # clojure-dev (5)
- # clojure-europe (17)
- # clojure-norway (22)
- # clojurescript (23)
- # core-logic (1)
- # cryogen (1)
- # datomic (1)
- # dev-tooling (7)
- # emacs (6)
- # fulcro (63)
- # guix (1)
- # hyperfiddle (14)
- # integrant (2)
- # lsp (6)
- # missionary (4)
- # nbb (42)
- # overtone (9)
- # reitit (8)
- # specter (3)
- # sql (2)
- # squint (7)
- # tools-build (9)
tools.build uber
function seems to create a multi-release uberjar by default, so I am trying to understand the benefits with respect to deploying a Clojure service as an uberjar.
Are these correct reasons for using multi-release uberjar and are there further reasons to use a multi-release uberjar
1. run a Clojure service on a different version of the JVM than it was built upon (avoiding the need to create an uberjar for each release of Java that might be on the server environment) ?
2. use classes or jar files compiled elsewhere, potentially compiled with a different version of the JDK (i.e. library dependencies from Clojars / Maven) ?
I assume 1. is not significant when there is control over the JVM being used to run the service, e.g. in a containerised build and deploy.
I also assume a multi-release is more significant as the amount of Java interop is used in the service or library dependencies.
Thank you.
I can tell uber
to set the uberjar manifest to switch off the multi-release if there is a value to doing this
(build-api/uber {:basis project-basis
:class-dir class-directory
:main main-namespace
:manifest {"Multi-Release" "false"}
:uber-file uberjar-file})
I only noticed the uberjar was a multi-release as jdeps
command complained that I didn't pass a --multi-release <jdk-version> argument 🙂Like Uber doesn't make a multi release jar, but one of your dependencies is multi release and Uber is merging the keys in the manifests or something
Yes, that
The purpose of MR jars is to allow you to have JDK-specific classes in your jar, so you can lord different versions depending on available jdk stuff
Uber is just exploding and merging so one of your source jars is likely mr
Ah, so a multi-release uberjar is created when one of the libraries used in the project is a multi-release jar.
So any dependency jar that has "Multi-Release" "true"
in it's manifest sets that for the generated uberjar.
Now I am curious as to which jars are setting this, but it's probably not that valuable to know unless I experience an issue.
That all makes sense. Thanks