This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (9)
- # babashka (7)
- # beginners (190)
- # calva (5)
- # cider (12)
- # clara (1)
- # clj-kondo (26)
- # cljdoc (3)
- # cljsrn (5)
- # clojure (15)
- # clojure-australia (2)
- # clojure-czech (1)
- # clojure-europe (34)
- # clojure-germany (2)
- # clojure-nl (6)
- # clojure-spec (20)
- # clojure-uk (7)
- # clojurescript (6)
- # cloverage (1)
- # conjure (10)
- # core-async (18)
- # core-logic (1)
- # crux (2)
- # cursive (22)
- # data-science (1)
- # datalog (26)
- # datomic (35)
- # docker (1)
- # emacs (4)
- # etaoin (4)
- # fulcro (51)
- # jobs (2)
- # jobs-discuss (2)
- # joker (1)
- # leiningen (4)
- # mid-cities-meetup (1)
- # off-topic (22)
- # pathom (15)
- # re-frame (14)
- # reitit (5)
- # remote-jobs (1)
- # shadow-cljs (37)
- # specter (2)
- # tools-deps (43)
Hi all, I try to create an uberjar with
depstar using the
-X method. I.e. i updated my
deps.edn to have an alias specifying a
exec-arg. When running on my laptop
clojure -X:uberjar a jar is generated just fine. However when I try to create the jar from a docker container it fails with
The docker images I tried:
Execution error (FileNotFoundException) at java.io.FileInputStream/open0 (FileInputStream.java:-2). -X:uberjar (No such file or directory)
I want a self contained jar that I can run with
java -jar app.jar so skinny does not fit the bill.
Thank you Alex. I presume the 697 image will become available on docker hub soon. In the meantime I built the image locally and the
-X:uberjar works fine then.
@zetafish I'm planning an overhaul of my project's readme files this week to make that clearer (that some of the usage examples require 126.96.36.1997). I also need to update all of the
clj-new project stuff to generate projects that can work both ways.
I don't see it in the system properties when running code via 188.8.131.527 @dominicm -- there's
clojure.basis now, which is the path to the combined EDN file.
I see it was still present in 590:
> /usr/local/Cellar/clojure\@184.108.40.2060/220.127.116.110/bin/clojure Clojure 1.10.1 user=> (System/getProperty "clojure.libfile") "/Users/sean/.clojure/.cpcache/2731801087.libs" user=>
Ah, that could explain the bug I'm seeing. I thought it was being retained for backwards compatibility.
@dominicm Lots of breakage between the previous stable and the current stable 🙂 but if you change
(System/getProperty "clojure.libfile") to
(some-> (System/getProperty "clojure.basis") (str/replace #"\.basis$" ".libs")) you can still get at the old file (although, as I recall, the
basis file now contains the libs list as an element?)
(some-> (System/getProperty "clojure.basis") (slurp) (edn/read-string) :libs) should be the same data.
yeah, I removed it in 697. we've never publicly doc'ed it and I was not aware of anyone using it (other than add-libs which won't work with latest anyways) so I didn't think there was any reason to retain it
If I could reliably identify my lib in the classpath, then that'd be fine 🙂. Happy to switch over to the newnew system when that comes out too.
We also use it in our internal tool based on the lib, but I can update that the same way
The problem with that (getting a file from the command line) is that the desired order for repos such as ours is:
and because "last one wins" etc for some combinations of aliases, you can't always specify "repo-master` via some sort of
System -> User (happy to exclude with -Srepro) -> repo-master (this is missing) -> Project -> -Sdeps
Although, if you could specify an arbitrary list of files to read in order via
-Sdeps-file (and they didn't have to be called
deps.edn) then we could use
-Sdeps-file ../versions/master-deps.edn:project-deps.edn and not have an actual
deps.edn file in each subproject in the repo.
-Sdeps-path might be a more appropriate name and I'd be happy to support it in deps.clj (and change the name). It already does this now but for just one file
-Sdeps-overrides could also work as a name to indicate that it doesn't read any other files than these
but I'm relatively sure all of this can be done using scripting as well:
merge the configs yourself, provide it via
-Sdeps and move the local deps.edn aside (hacky)
also I'm relatively sure these things are in some row/column in an excel sheet somewhere on Alex's computer :)
Our deps files are pretty big -- too big to go on the command line I think as merged data -- and, as you say, that's a hacky approach.
(also, we're not about to switch from the official Clojure CLI to a third party tool at this point, esp when we would need multiple different binaries for different parts of our dev/test/staging pipeline, whereas we can have just one CLI install)
And, yeah, I've already brought this up with Alex (which was how I learned that it's similar to something the Datomic Ions users have asked for) so, yeah, I'll bet it's already in a spreadsheet. I don't know what I'd prefer in terms of a solution. As long as it addresses the deps ordering shown above and is officially supported, I'll be happy with whatever Cognitect/Nubank think is the best approach 🙂
@seancorfield small details: deps.clj also runs using
JVM as a dependency but yeah I don't expect you to switch - I was just thinking out loud about this option. I'm blathering too much.
I just pushed 0.0.10 - there was something with the clojars deploy token, missed that. But now it works:
(so I'm in /tmp, but I'm using deps.edn from clojurescript in $HOME/git/clojurescript)
Just putting this here for now, but there is a new prerelease clj available - 18.104.22.1688. Has a small fix to -X error handling and more importantly an update on how dep expansion works when multiple transitive versions of the same dep are in the tree to fix a case where a dep can be incorrectly omitted.
Building our uber JARs for our 14 processes seems to produce near-identical results between .697 and .708 -- there are variations from run-to-run based (I assume) on differing timestamps etc but nothing more than 150 bytes on JAR files that range from 30MB to 70MB, so that all looks reasonably sane.
(if dependencies were missing we'd have known about it by now on .697 and 150 bytes here and there isn't likely to indicate an entire dependency coming or going)