You aren't wrong.

Thank you!

Keep in mind if multiple methods match for a given dispatch value, you'll need to manually set which is preferred.

What makes you think you are compiling http-kit there?

it is a dependency of that project and the class https://github.com/http-kit/http-kit/blob/v2.7.0/src/org/httpkit/client.clj#L10 - Is that not the problem? I might be off

I don't see anything that indicates any compilation in the output you showed

(compilation of java source to class files)

oh sorry, I'll post the full stack trace

There likely will not be any evidence in the stacktrace

And that is likely the problem, http-kit has java source code that needs to be compiled

ah, yeah, but this used to work before?

Did the clojure build tool change w.r.t. compiling?

I see a step in their deps.edn https://github.com/http-kit/http-kit/blob/v2.7.0/deps.edn#L8

Ok it seems I just need to add clojure -X:deps prep before building the uberjar... https://clojure.org/guides/deps_and_cli#prep_libs Thank you, you comment made me realize a few more things

what is the rationale for consuming http-kit as a git dep instead of a maven dep?

yeah, it's not a rationale but another error I faced

Execution error (ExceptionInfo) at clojure.tools.deps.extensions.maven/get-artifact (maven.clj:167).
Could not transfer artifact http-kit:http-kit:jar:2.7.0 from/to clojars (): status code: 416, reason phrase: Range Not Satisfiable (416)

% clj -Sdeps '{:deps {http-kit/http-kit {:mvn/version "2.7.0"}}}'    
Downloading: http-kit/http-kit/2.7.0/http-kit-2.7.0.pom from clojars
Downloading: http-kit/http-kit/2.7.0/http-kit-2.7.0.jar from clojars
Clojure 1.11.1
user=>

$ clj -Sdeps '{:deps {http-kit/http-kit {:mvn/version "2.7.0"}}}'    
Error building classpath. Could not transfer artifact http-kit:http-kit:jar:2.7.0 from/to clojars (): status code: 416, reason phrase: Range Not Satisfiable (416)

Something in your user deps.edn perhaps? Does this work for you?

clj -Srepro -Sdeps '{:deps {http-kit/http-kit {:mvn/version "2.7.0"}}}'

Uhm, good point - tried but nope, same error

$  clj -Srepro -Sdeps '{:deps {http-kit/http-kit {:mvn/version "2.7.0"}}}'
Error building classpath. Could not transfer artifact http-kit:http-kit:jar:2.7.0 from/to clojars (): status code: 416, reason phrase: Range Not Satisfiable (416)

I've seen some suggestions that if you get that error you should check for a partially downloaded jar in ~/.m2 and delete it

Hey, that worked!

one thing i like to do is add a form like

(require 'clojure.repl)
(clojure.repl/pst (Exception. "trace") 50)

that's really clever

Don’t think uber should load anything

More likely getting loaded twice during compile but hard to say

i ran b/uber from the repl and nabbed the compile script from write-compile-script! . followed the stack traces as @U11BV7MTK suggested, and i see that at line 15, (compile 'crossbeam.routes.N) is called which (through 15+ namespaces of requires) loads the target namespace, and then at line 106, there's (compile 'crossbeam.target-namespace)

given that lots of people use this and no one seems harmed by it lol, i'm guessing that this isn't worrisome for things like records?

and for some reason, I thought compile was transitive and would compile everything in the require'd tree as well as the target namespace

i would only compile things once. You can end up with maddening issues like type X cannot be cast to type X

yeah, that's what i thought. i'm not sure how these two interplay, so maybe it's okay?

why are you calling compile twice (lines 15 and 106?)

i'm not, this is part of`tools.build`'s uberjar function

https://github.com/clojure/tools.build/blob/e2c97f0fc5673b27fa64894721d23cd950e52887/src/main/clojure/clojure/tools/build/tasks/compile_clj.clj#L27-L44

Are you compiling just the main ns or all nses?

(I generally recommend only compiling the main ns -- since it's transitive -- and then adding only nses you know are dynamically loaded which wouldn't be reached by transitive compilation from main)

this is our uberjar function:

(defn uberjar
  [_]
  (let [basis (b/create-basis {:project "deps.edn"})]
    (clean nil)
    (b/copy-dir {:src-dirs ["src" "resources"]
                 :target-dir class-dir})
    (b/compile-clj {:basis basis
                    :src-dirs ["src"]
                    :class-dir class-dir})
    (b/uber {:class-dir class-dir
             :uber-file uberjar-file
             :main 'crossbeam.core
             :basis basis
             :manifest {"Add-Opens" "java.base/java.nio"}
             :exclude [#"^META-INF/license/LICENSE.*"]})))

your comment and reading the tools.build code makes me wonder if we should be passing in :ns-compile instead of :src-dirs

Yes. Specify the main ns with that 🙂

hmm that solved the double-load issue. i'll have to test the resulting jar to make sure we're not doing anything dynamic and naughty lol

(`:src-dirs` is also needed I think? ... hmm, maybe not if you specify :ns-compile ... I think I do it just by default since :src-dirs is used for other stuff in the build pipeline and I pass options all the way through in general)

the docs say it only needs :src-dirs if there's no paths in the basis (which we are providing with our deps.edn)

Ah, yeah, that would be it...

maybe the tools.build guide should recommend :ns-compile instead of :scr-dirs. it looks like whoever wrote this copied the example directly and only lightly modified it lol

thanks everyone, glad to solve this

> maybe the tools.build guide should recommend :ns-compile instead of :scr-dirs. Post on http://ask.clojure.org about it 🙂

I can clean that up

src-dirs is actually not even needed (will use :paths from basis by default)

thank you, i'll close the github issue i was in the process of writing lol

I'm also only using :ns-compile [main-ns] by default, weird things happen with graalvm native-image if you don't. lein's behavior same: :aot [main-ns], never :aot :all

Yeah... "AOT ALL THE THINGS!!!" always made me nervous 🙂

I've updated the tools.build guide and tweaked the tools.build docstring for compile-clj