This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-25
Channels
- # aleph (9)
- # announcements (2)
- # babashka (32)
- # babashka-sci-dev (72)
- # beginners (77)
- # calva (1)
- # cider (3)
- # clj-kondo (19)
- # clojure (61)
- # clojure-brasil (13)
- # clojure-europe (25)
- # clojure-italy (1)
- # clojure-nl (2)
- # clojure-norway (27)
- # clojure-uk (23)
- # clojuredesign-podcast (6)
- # clojurescript (12)
- # conjure (2)
- # core-typed (3)
- # cursive (6)
- # datalevin (2)
- # datomic (13)
- # emacs (9)
- # events (19)
- # fulcro (6)
- # graphql (11)
- # gratitude (2)
- # helix (3)
- # honeysql (16)
- # jobs (1)
- # lsp (89)
- # malli (33)
- # meander (14)
- # off-topic (87)
- # pathom (4)
- # polylith (7)
- # portal (4)
- # practicalli (1)
- # rdf (6)
- # reagent (2)
- # releases (8)
- # remote-jobs (1)
- # shadow-cljs (59)
- # sql (8)
- # tools-deps (14)
- # xtdb (18)
@cap10morgan Some feedback on the PR: I think it's worth figuring out why resources will be in the uberjar by default, other than "it seems to work". Also I think it's better to use a temporary directory to copy bb.edn into than the resources directory, as there might already be such a directory and you would be overwriting the contents.
babashka has its own old version of depstar built in for making uberjars, perhaps we could tweak that to include certain files as well
or we could move to the new tools.build uberjar code instead. it's fully compatible with bb except for the basis stuff, which we don't really need
but let's move in the smallest step possible and just do with what we have right now
looks like in depstar it's just b/c its on the classpath: https://github.com/seancorfield/depstar/issues/27
so we could just put a temp dir on the classpath while we're building the uberjar
instead
@cap10morgan yes, but resources isn't always on bb's classpath, only if you add that
I tried out the tools.build api a little but got confused by the basis stuff and how it would relate here
probably just on the classpath where I tried it (e.g. in the :paths
vector in my deps.edn
files)
so I'll just do it the way you suggest instead
you only need a classpath in the end. if you have that, you don't need the basis stuff which depends on mvn etc
seemed like the uber
task in tools.build wanted a basis, but maybe it isn't required or it doesn't need much of it
yes, the uber task wants a basis but once you replace that with a classpath, the rest of the code works.
ah ok
I can try converting it to that if you want
@borkdude for the temp dir that we copy the bb.edn
into and add to the classpath while building the uberjar, you think it matters if it's inside the project root (vs. just the system's temp dir)?
it gets deleted once the jar is built
pushed the system temp dir version just now, but happy to change if you want
@cap10morgan I haven't tried, but won't deps from bb.edn be fetched again when you execute the uberjar, while they are already within the uberjar, when you start that uberjar? We could also write something in the uberjar's manifest about the config.
not sure, I haven't tried that either
Well I don't see any special handling not to do this, it seems the bb.edn is picked up as if you're not inside an uberjar
not sure I follow
like a bb.edn in the same dir as the .jar file?
yeah I saw that too
I can make it not do that
I think we should be conservative and only copy the pods config into some uniquely named file and write something in the manifest file that pods should be loaded from there
I think the latest code in the PR already skips using a bb.edn
in the same dir as the .jar
file. Because of the cond
. It will hit the jar
branch and either find a file in the jar or not, but if it doesn't it should just return nil
, not skip down to the :else
where the ./bb.edn
loading happens.
yeah that's good but the uberjar invocation will still trigger dependency downloading which should not happen anymore
seems reasonable
in the future we could support bundling the pods with the uberjar too but this is out of scope for now ;)
hmm... it's not putting deps into the uberjar
oh, perhaps b/c if its only declared in bb.edn
's :deps
, I need to manually add it to my uberjar classpath? b/c clojure -Spath
will only give me the deps.edn
ones, huh?
from the babashka book: bb -cp $(*clojure* -A:remove-clojure -Spath) uberjar foo.jar -m foo
that's how I'm getting my classpath for the uberjar I'm testing with
ok, yeah, eliding that worked (even better)
:pods only is pushed
a minor thing but:
->> bb-edn-pods (hash-map :pods)
can be written as {:pods bb-edn-pods}
, I find that a little easier to readYep, no problem
pushed
ok, now we should also have tests for this. One thing to note is that local sources are always resolved relative to the bb.edn file, unless you set --deps-root
but I don't know how that plays out if you invoke the uberjar from another directory now, e.g.
/tmp/foo $ bb /tmp/bar/uberjar.jar
my simple tester jar works from a different dir
w/ a dep
writing up a test now
Maybe this part of the code isn't hit anymore: https://github.com/babashka/babashka/blob/72ae6638422c542055dda8fc068f995cbfd9f61f/src/babashka/impl/deps.clj#L63 in the uberjar, since we cut out the deps part, so that makes sense.
ok just pushed a test. let me know if there are other aspects you'd like tested