I can’t use aliases here, because aliases are “fixed” in the edn file, and I want to override a local dep with a maven dep just for the sake of creating a JAR library, so the maven version might be different on different branches etc. It’s a small addition to depstar, I can add it in my fork and open a PR for you, if you wish. Basically I’m using the monorepo approach and when trying to build a JAR I get
Manifest type not detected when finding deps for localize/zinc in coordinate #:local{:root "/Users/golan/dev/git/clj-data/zinc"}
Which totally makes sense.
Anyway that’s my motivation.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}}}
But when I run clojure -X:jar :jar '"app.jar"' :verbose true
, the clojure source is being added, but the assets in the "assets" folder do not show up in either in the verbose output, or in the jar itself. Am I doing something wrong or missing a step? Thanks!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.