hi all...just playing with practically and depstar for uberjar, and for somer eason, it seems that dependency libs don't get included in uberjar... Eg. I created sample project via "app" template, added "omniconf" lib via to deps.edn as :

:deps  {org.clojure/clojure    {:mvn/version "1.10.1"}
         com.grammarly/omniconf {:mvn/version "0.4.2"}}

clj -X:project/uberjar :main-class me.marcinko.woah :jar woah-uber.jar :verbose true :aot false

Building uber jar: woah-uber.jar
src
src/me/marcinko/woah.clj
resources
resources/.keep
/home/vmarcinko/.m2/repository/org/clojure/clojure/1.10.1/clojure-1.10.1.jar
/home/vmarcinko/.m2/repository/org/clojure/core.specs.alpha/0.2.44/core.specs.alpha-0.2.44.jar
/home/vmarcinko/.m2/repository/org/clojure/spec.alpha/0.2.176/spec.alpha-0.2.176.jar
/usr/local/lib/clojure/libexec/exec.jar

Processing pom.xml for {me.marcinko/woah {:mvn/version "0.1.0-SNAPSHOT"}}

Anyone knows what I'm doing wrong?

later when I tried to start the jar file, I got following of couse:

Caused by: Could not locate omniconf/core__init.class, omniconf/core.clj or omniconf/core.cljc on classpath.

@vmarcinko What is the :project/uberjar alias exactly? I seem to recall @jr0cket fixed a bug recently with his deps.edn in that area...

;; Uberjar archive of the project, including Clojure runtime
  ;; clojure -X:project/uberjar :main-class domain.application
  ;; clojure -X:project/uberjar :jar '"project-name.jar"' :main-class domain.application
  :project/uberjar
  {:replace-deps {seancorfield/depstar {:mvn/version "1.1.126"}}
   :exec-fn      hf.depstar/uberjar
   :exec-args    {:jar        "uber.jar"
                  :aot        true
                  :main-class project.core}}

You need to update to his latest then.

ok, now i checked, definitely bug with practically, since when I used :uberjar alias from generated project's deps.edn, everything worked fine..

It should be :extra-deps there not :replace-deps

@vmar FYI, the :project/uberjar briefly has :replace-paths [ ] and replace-deps added to it. This was a bug and has been fixed now. It was added in error as a similar tool recommended busing this setting and it was also applied to depstar in error. Sorry for the confusion

depstar 2.0 will work with :replace-deps (I'm changing how it computes the basis)

@jr0cket Actually, I feel bad to written the last comment I just removed... I very appreciate all your contribution to clojure community, it was just typical unbfortunate situation when newbie is starting to experiment with some new tech, and accidetally stumble at the very beginning of playing with it to a bug, but the newbie in that moment thinks he has done something wrong

When one gets experienced, then he knows this stuff worked before, so there's a good chance a lib got broken etc...

I am always an @ mention away if you have issues with my work. Nothing is perfect and I can't fix anything if I don't know about it 😁

no problem...actually, I never used depstar before so I assumed it was problem there, so that's why I came to this channel instead of pinging you

but just when I was typing here, then I realized I haven't tried depstart directly, so ...

@seancorfield good to know about V2 of depstar, I will keep an eye out for it. I guess I was too bleeding edge with the replace change 😆

For a bit of background on that: V1 uses the current/runtime basis (effectively) by just looking at what is on the current classpath and that's what goes into the JAR (excluding depstar itself). That's why it also has a :classpath option, so you can explicitly override the list of things it will put in the JAR. This is both simple and easy: when you ask depstar to build a JAR, it will use whatever dependencies you've asked for (via aliases to the CLI), so it needs no additional options to control how to build the basis. The downside is that depstar cannot have any other dependencies because it wouldn't know how to exclude them from the JAR (and might end up conflicting with versions of those same dependencies you are trying to use in the project). V2 will compute the project basis using tools.deps.alpha, which means that depstar can have any dependencies it wants and, using :replace-deps, it won't "leak" into the JAR file. However, that means that it will need options to figure out what aliases need to be used when reading/merging the various deps.edn files, and also potentially, an option to ignore the user-level deps.edn file (like the CLI's -Srepro option). It will also mean you can't just build a JAR from deps provided on the command-line.

(there's a 2.0 milestone in the depstar repo which has information on this)