Fork me on GitHub

anything wrong with clojars? tried to publish my package usual way via “lein deploy clojars” and got this


the release seems to be corrupted on clojars: but clojure -Srepro -Sdeps '{:deps {binaryage/dirac {:mvn/version "1.5.8"} org.clojure/clojurescript {:mvn/version "RELEASE"} clj-logging-config {:mvn/version "1.9.12"}}}' -m dirac.main is giving me Error building classpath. Could not find artifact binaryage:dirac:jar:1.5.8 in central () I’m unable to diagnose this further. deps.edn should be using clojars.


I don't know what's going on with lein and checksums, but for this particular issue, 1.5.8 downloads fine for me:


$ clojure -Srepro -Sdeps '{:deps {binaryage/dirac {:mvn/version "1.5.8"} org.clojure/clojurescript {:mvn/version "RELEASE"} clj-logging-config {:mvn/version "1.9.12"}}}' -m dirac.main
Downloading: org/clojure/clojurescript/maven-metadata.xml from 
Downloading: binaryage/dirac/1.5.8/dirac-1.5.8.pom from 
Downloading: org/clojure/clojurescript/1.10.597/clojurescript-1.10.597.pom from 
Downloading: clj-logging-config/clj-logging-config/1.9.12/clj-logging-config-1.9.12.pom from 
Downloading: org/clojure/core.async/1.0.567/core.async-1.0.567.pom from 
Downloading: org/clojure/tools.logging/1.0.0/tools.logging-1.0.0.pom from 
Downloading: org/clojure/tools.cli/1.0.194/tools.cli-1.0.194.pom from 
Downloading: org/clojure/pom.contrib/1.0.0/pom.contrib-1.0.0.pom from 
Downloading: funcool/cuerdas/2.2.1/cuerdas-2.2.1.pom from 
Downloading: com/rpl/specter/1.1.3/specter-1.1.3.pom from 
Downloading: me/raynes/conch/0.8.0/conch-0.8.0.pom from 
Downloading: clj-sub-command/clj-sub-command/0.5.1/clj-sub-command-0.5.1.pom from 
Downloading: ring/ring-defaults/0.3.2/ring-defaults-0.3.2.pom from 
Downloading: binaryage/devtools/1.0.0/devtools-1.0.0.pom from 
Downloading: org/clojure/tools.logging/0.2.6/tools.logging-0.2.6.pom from 
Downloading: log4j/log4j/1.2.16/log4j-1.2.16.pom from 
Downloading: org/clojure/tools.analyzer.jvm/0.7.3/tools.analyzer.jvm-0.7.3.pom from 
Downloading: org/flatland/useful/0.10.6/useful-0.10.6.pom from 
Downloading: org/clojure/tools.cli/0.4.1/tools.cli-0.4.1.pom from 
Downloading: ring/ring-anti-forgery/1.3.0/ring-anti-forgery-1.3.0.pom from 
Downloading: org/clojure/tools.analyzer/0.7.0/tools.analyzer-0.7.0.pom from 
Downloading: org/clojure/tools.analyzer/0.7.0/tools.analyzer-0.7.0.jar from 
Downloading: org/clojure/tools.logging/1.0.0/tools.logging-1.0.0.jar from 
Downloading: org/clojure/tools.cli/1.0.194/tools.cli-1.0.194.jar from 
Downloading: org/clojure/tools.analyzer.jvm/0.7.3/tools.analyzer.jvm-0.7.3.jar from 
Downloading: org/clojure/tools.macro/0.1.1/tools.macro-0.1.1.jar from 
Downloading: clj-logging-config/clj-logging-config/1.9.12/clj-logging-config-1.9.12.jar from 
Downloading: org/flatland/useful/0.10.6/useful-0.10.6.jar from 
Downloading: ring/ring-defaults/0.3.2/ring-defaults-0.3.2.jar from 
Downloading: org/clojure/clojurescript/1.10.597/clojurescript-1.10.597.jar from 
Downloading: funcool/cuerdas/2.2.1/cuerdas-2.2.1.jar from 
Downloading: binaryage/devtools/1.0.0/devtools-1.0.0.jar from 
Downloading: ring/ring-anti-forgery/1.3.0/ring-anti-forgery-1.3.0.jar from 
Downloading: clj-sub-command/clj-sub-command/0.5.1/clj-sub-command-0.5.1.jar from 
Downloading: com/rpl/specter/1.1.3/specter-1.1.3.jar from 
Downloading: me/raynes/conch/0.8.0/conch-0.8.0.jar from 
Downloading: log4j/log4j/1.2.16/log4j-1.2.16.jar from 
Downloading: binaryage/dirac/1.5.8/dirac-1.5.8.jar from 
Downloading: org/clojure/core.async/1.0.567/core.async-1.0.567.jar from 
Exception in thread "main" clojure.lang.ExceptionInfo: Unable to locate Chromium executable
=>  {:config {:verbosity 1, :command :launch, :profile "default", :log-level "INFO"}}
	at dirac.main.actions.launch$locate_chromium_by_search.invokeStatic(launch.clj:36)
	at dirac.main.actions.launch$locate_chromium_by_search.invoke(launch.clj:30)
	at dirac.main.actions.launch$locate_chromium.invokeStatic(launch.clj:43)
	at dirac.main.actions.launch$locate_chromium.invoke(launch.clj:40)
	at dirac.main.actions.launch$launch_BANG_.invokeStatic(launch.clj:192)
	at dirac.main.actions.launch$launch_BANG_.invoke(launch.clj:182)
	at dirac.main$dispatch_BANG_.invokeStatic(main.clj:18)
	at dirac.main$dispatch_BANG_.invoke(main.clj:15)
	at dirac.main$_main.invokeStatic(main.clj:30)
	at dirac.main$_main.doInvoke(main.clj:24)
	at clojure.lang.RestFn.invoke(
	at clojure.lang.AFn.applyToHelper(
	at clojure.lang.RestFn.applyTo(
	at clojure.lang.Var.applyTo(
	at clojure.core$apply.invokeStatic(core.clj:665)
	at clojure.main$main_opt.invokeStatic(main.clj:491)
	at clojure.main$main_opt.invoke(main.clj:487)
	at clojure.main$main.invokeStatic(main.clj:598)
	at clojure.main$main.doInvoke(main.clj:561)
	at clojure.lang.RestFn.applyTo(
	at clojure.lang.Var.applyTo(
	at clojure.main.main(


Do you see it even trying to find it in clojars? Or just in maven central?


I was unable to figure out what exactly tools deps is doing, I think the message about maven is wrong, it should be trying clojars as well. but doing another deploy using the same scripts worked, so version 1.5.9 is good


btw. I repeated the same thing, first deploy of 1.5.9 failed with “no checksums provided” and then I fixed the leiningen and deployed again with success, and the deployed file is correct


btw. this project is not deployed to maven central, and never was


the strange thing is that 1.5.8 looks good on via web interface


Clojars tries to make deploys atomic. Deploys go to a staging repo, then validation is performed on the deploy to try to confirm it is correct (that's where the no checksums provided for dirac-1.5.8.jar.asc message comes from). If all the validation succeeds, the deploy is then moved in to the real repo. So you can redeploy the same version if it failed. And 1.5.8 seems fine to me - it downloads for me w/o issue. The reason tools.deps is reporting that it can't find it in Maven Central is because it doesn't know where artifacts live, it just asks each repo from its list of repositories in order, and Maven Central is first. If it can't find it in one repo (meaning it got a 404), it will try the next repo in the list. If no repo has it, it will report that it could not find it in the first repo it tried I believe.


If you rm ~/.m2/repository/binaryage/dirac/1.5.8 and rerun your tools.deps invocation, does it then download it?


so this works for you?


Yep, see my output above in this thread


I don't know much about deps - is there a way to have it print the repos it is using?


don’t know, I didn’t go that deep to look into its sources


so it works for you, so maybe it is just some cache issue, maybe between me and clojars


because version 1.5.9 works as expected


so it is not caused by misconfigured tools.deps on my machine


That's a good point - Fastly does cache 404s, so it's possible the edge node that is serving you has cached that 1.5.8 does not exist, but the one serving me did not. That means that 1.5.8 should work for you in < 24 hours, since that's the TTL


ok, let’s wait, I will try it again tomorrow and report back


thanks for your help


My pleasure

Alex Miller (Clojure team)14:03:07

Re "If no repo has it, it will report that it could not find it in the first repo it tried I believe." this is correct. If there are multiple failures, tools.deps reports the first one (which repo that is is kind of arbitrary), but really that typically means it was not able to get from any repo.

Alex Miller (Clojure team)14:03:29

this is hard to "fix" as there's no way to know which repo it was supposed to have been downloaded from. you could report all, but in some cases (multiple repos configured), you would see a flood of errors which would not actually give you any additional info.


hmm, the message could be general without mentioning a repo or print something like “tried central (…) and 2 others” this way it is quite misleading, because I spent quite some time fishing in my config files whether clojars is really configured as my secondary repo


I ended up hardcoding :mvn/repos in my deps.edn just to be sure, but I couldn’t force their order to really confirm that clojars was actually tried

Alex Miller (Clojure team)14:03:58

these messages are just coming out of maven and are only one of many errors that could be reported (differing only in message). doing what you just suggest means basically parsing and analyzing error message strings emitted from maven


ah, nevermind, I see

Alex Miller (Clojure team)14:03:22

if you use the mvn tool itself, I think it makes similar choices iirc