Hi there, I'm attempting to roll a thin jar that contains some clojure code, as well as a few assets which are in a separate folder. I've put together the following alias:

{:jar {:extra-paths  ["assets"]
       :replace-deps {com.github.seancorfield/depstar {:mvn/version "2.0.216"}}
       :exec-fn      hf.depstar/jar
       :exec-args    {:group-id    org.my-group
                      :artifact-id app
                      :version     "0.1.0-SNAPSHOT"
                      :sync-pom    true}}}

Ah, ok, I think I see the issue. I wasn't using any other aliases, but nevertheless :extra-paths in the :jar alias appears to be ignored. If I roll that out into a separate alias, and then explicitly include that via the :aliases option, then the relevant assets are included:

{:assets {:extra-paths ["assets"]}
 :jar    {:replace-deps {com.github.seancorfield/depstar {:mvn/version "2.0.216"}}
          :exec-fn      hf.depstar/jar
          :exec-args    {:group-id    org.my-group
                         :artifact-id app
                         :version     "0.1.0-SNAPSHOT"
                         :sync-pom    true
                         :assets      [:assets]}}}

@zalky That is explained in the depstar README (pretty much that exact use case).

You need :aliases in :exec-args — you have :assets

:aliases [:assets]

@seancorfield, thanks I think I misunderstood that to mean if I had any extra aliases in addition to the the one the depstar one.

There are two contexts here: the context that the CLI uses to run depstar and the context depstar uses to figure out what goes into the JAR file.

Aliases you provide to run depstar only affect the former. The latter context is entirely controlled by the :aliases in exec args that tell depstar how to build the JAR file.

In addition, depstar ignores your user deps.edn file by default when building the context for the JAR file — unless you explicitly tell depstar :repro false — this is to ensure that your JAR file build is reproducible, i.e., based just on the project deps.edn file.

(well, root + project)

Gotcha, thanks for clarifying. The distinction between lauching the tool and building the jar makes more sense, thanks!

As I said yesterday, to Golan: “The command-line … can only affect how the CLI runs a program -- that information is all gone by the time the [program] is actually running and therefore it can’t affect how the program behaves.”

Do you have any insight why it is gone? There's probably a good reason, but I imagine the computed project basis might be useful to have at run-time.

The command-line stuff is used by the clojure script to figure out the classpath to run the program. The program itself has no idea how it was invoked, except for the classpath itself — which isn’t enough to say how the classpath was created.

The computed project basis is independent of the basis used to run the program. And even the runtime basis doesn’t show how that basis was created.

That’s how the Clojure CLI works.

And depstar can’t use the runtime basis to build the JAR because it contains depstar and all of its dependencies — instead of your project’s code and dependencies.

Ah, super helpful, that last part especially.