Clojurians Log v2
clojure 2026-05-11
Anyone else having issues with Maven? When I run any clj command that downloads Maven deps, I'm constantly seeing:
32.63 Execution error (ExceptionInfo) at clojure.tools.deps.extensions.maven/get-artifact (maven.clj:167).
32.63 Could not find artifact com.cognitect:transit-java:jar:1.0.362 in central (
Can you attach the referenced full report too?
Yes I've been experiencing the same issue for different dependencies on different runs. Has been happening at least since yesterday. I can't get it to reproduce locally. Only in GCP's Cloud Build. It's a bit challenging but I'll see if I can get a full report.
Actually just got the error to happen locally when running clojure -Spom small excerpt:
Downloading: com/google/cloud/google-cloud-vision/3.90.0/google-cloud-vision-3.90.0.jar from central
Downloading: com/github/steffan-westcott/clj-otel-sdk-extension-autoconfigure/0.2.10/clj-otel-sdk-extension-autoconfigure-0.2.10.jar from clojars
Downloading: slingshot/slingshot/0.12.2/slingshot-0.12.2.jar from clojars
Error building classpath. Could not find artifact org.eclipse.jetty.websocket:jetty-websocket-jetty-api:jar:12.1.8 in central (Just ran it again, same error
clojure -Spom
Error building classpath. Could not find artifact org.eclipse.jetty.websocket:jetty-websocket-jetty-api:jar:12.1.8 in central (ran one more time and it ran successfully
also seeing build failures in CircleCI - similar maven problems
Error building classpath. Could not find artifact jfree:jcommon:jar:1.0.15 in central (I can get it reproduced almost always when I nuke ~/.m2 so that it downloads everything
Full report at:
/var/folders/0p/vtdv4p053pd6gkx8d5p98h000000gn/T/clojure-8824913635048931549.edn
➜ cat /var/folders/0p/vtdv4p053pd6gkx8d5p98h000000gn/T/clojure-8824913635048931549.edn
{:clojure.main/message
"Execution error (ExceptionInfo) at clojure.tools.deps.extensions.maven/get-artifact (maven.clj:167).\nCould not find artifact com.cognitect:transit-java:jar:1.0.362 in central (fwiw, adding the google central mirror to :mvn/repos seems to have cleared our builds.
"google-maven-central-mirror" {:url "
you just add this to mvn/repos?
or do you need to somehow disable/remove the default one?
@roklenarcic Add it in your deps.edn file. It should look something like this:
{:paths ["src"]
:aliases
{,,,}
:deps
{,,,}
:mvn/repos
{"google-central" {:url "thanks
FYI, Maven itself supports mirrors explicitly, and tools.deps will use those https://maven.apache.org/guides/mini/guide-mirror-settings.html
you then don't need to modify your deps.edn at all
Ran into this myself this morning. We use BitBucket Pipelines at work, and it keeps a Maven cache... but it deletes the cache every few weeks so it gets rebuilt fresh with whatever new dependencies you have then... and of course, 429. Thanks for the pointer to the Google Central mirror -- that got me past it!
we were discussing the same in #leiningen FYI https://clojurians.slack.com/archives/C0AB48493/p1778381725840669
I'm having the same problem. Sonatype's rate limiting is so aggressive that a single-threaded invocation of the clojure cli (e.g.: clojure -Sthreads 1 ...) can't download all my dependencies for a single build (with a fresh .m2 cache). And I don't have that many top-level dependencies!
My firm seems to be blocked from the Google Maven mirror mentioned previously in this thread, so that workaround doesn't work for me.
Has anyone figured out a workaround?
@alexmiller More generally, it seems that Clojure's Maven resolver needs to honor the Retry-After: header in the 429 response, pause that amount of time, and then retry--rather than aborting? Or are there reasons this won't work?
Clojure uses the official Maven libraries for access
so that's not even something I control
This might be a good time to revisit whether there's a way to let deps.edn express a repository ordering like you can in a maven config xml. I think Maven always searches in listing order and since deps.edn is a map there's no way to express the ordering in a deterministic way
I could be 100% wrong about that though
no, that's correct. but also, it is hardcoded to always check maven central first, then clojars, then user specified repos
Maven mirrors and proxies are both supported and the recommended way to "swap out" the Maven central location though
there are https://maven.apache.org/resolver/configuration.html that might be useful, specifically, messing with the aether.transport.http.... ones. You can get these to take effect in the Clojure CLI by setting the env var CLJ_JVM_OPTS ala:
export CLJ_JVM_OPTS=aether.transport.http.retryHandler.interval=10000I've also opened a support case with sonatype to see if there's more info to glean
I believe that tools.deps' usage of the maven resolver already honors the Retry-After: header, and retries (based on my testing)
Nope, I lied. I had tested lein from main, not tools.deps. Lein does honor retry-after, but I'm not sure what triggers that. It's using pomegranate without any special settings, and pomegranate doesn't seem to have anything special to enable it.
Thanks Alex. For reference, my data points are:
• Unsurprising: A CI build in company infra; likely competing with other builds using Maven libraries on the same virtualized/NAT'd IP address.
• Surprising: A local build, after disconnecting from the VPN, after mv .m2 .m2.backup fails!
@dvorme I think the limit is really low; I can trigger it easily from my local machine if I have a project with a moderate amount of deps and I remove .m2/repository/.
Both lein and tools.deps are using the same maven lib so it would be surprising if they did not behave similarly
This is 100% a you're holding it wrong problem on our end, but we managed to befuddle ourselves for a bit by replacing central with the Google mirror and then having a bunch of builds fail because they were using delaguardo/setup-clojure with cli:latest.
This would then blow up when we'd run -T commands because:
• the root deps.edn inside the clojure.tools.deps.edn we got with the latest CLI points to 1.12.5 as of today
• make-classpath2 (correctly) ignores your local :deps when you're setting up to run a -T command, but doesn't ignore your local :repos key
• the Google mirror didn't actually have the Clojure 1.12.5 jar yet, so the dep fetching phase failed
Our fault, no fix needed. Only mentioning it in case someone else has the same brief confusing "wait, but all of my deps.edns are asking for Clojure 1.12.4" moment we did.
@alexmiller That was my expectation as well, but they do behave differently. lein blocks and retries, tools.deps throws an exception immediately:
$ clojure -M:deps
Error building classpath. Failed to read artifact descriptor for org.clojure:tools.deps.cli:jar:0.15.131
org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.clojure:tools.deps.cli:jar:0.15.131
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:255)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:171)
at org.eclipse.aether.internal.impl.DefaultRepositorySystem.readArtifactDescriptor(DefaultRepositorySystem.java:263)
at clojure.tools.deps.extensions.maven$read_descriptor.invokeStatic(maven.clj:115)
at clojure.tools.deps.extensions.maven$fn__1340.invokeStatic(maven.clj:143)
at clojure.tools.deps.extensions.maven$fn__1340.invoke(maven.clj:143)
at clojure.lang.MultiFn.invoke(MultiFn.java:244)
at clojure.tools.deps$expand_deps$children_task__959$fn__961$fn__962.invoke(deps.clj:299)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invokeStatic(core.clj:667)
at clojure.core$with_bindings_STAR_.invokeStatic(core.clj:1990)
at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1990)
at clojure.lang.RestFn.invoke(RestFn.java:428)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.RestFn.applyTo(RestFn.java:135)
at clojure.core$apply.invokeStatic(core.clj:671)
at clojure.core$bound_fn_STAR_$fn__5839.doInvoke(core.clj:2020)
at clojure.lang.RestFn.invoke(RestFn.java:400)
at clojure.lang.AFn.call(AFn.java:18)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
at java.base/java.lang.Thread.run(Thread.java:1474)
Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not transfer artifact org.clojure:tools.deps.cli:pom:0.15.131 from/to central (good to know. sonatype responded and indeed there are some rate limits that are being ratcheted down right now. sounds like maybe the lack of setting user agent may be contributing in CLI, but I'm talking to them. @tcrawley I will really like to intro you to the sonatype folks too - they have a repository consortium and it would be great to have clojars involved in that I think
Thanks for the update @alexmiller!!!
@alexmiller I'd love an introduction, thanks! I'll DM you.
They've updated the 429 page in response to my requests with more info https://central.sonatype.org/faq/429-error/
I think the 429 handling is down to a consequence of http client and which version of the Maven transporters is in use. there are of course, complications. :)
please try the new version of the Clojure CLI (dev only at the moment), without the Maven mirror if you have a chance https://clojurians.slack.com/archives/C06MAR553/p1779993239724119
Yup, tried 1654 with all the caches blown away and the mirror removed. Success.
Hi everybody, I'm trying to call a method which I can call directly but no by reflection, in which case I get :
Execution error (IllegalAccessException) at jdk.internal.reflect.Reflection/newIllegalAccessException (Reflection.java:394).
class clojure.lang.Reflector cannot access a member of ... with modifiers "public"clj -Sdeps '{:deps {org.apache.logging.log4j/log4j-core {:mvn/version "2.25.4"} commons-logging/commons-logging {:mvn/version "1.3.6"}}}'
Clojure 1.12.4
user=> (import '[org.apache.commons.logging Log LogFactory])
user=> (def logger (LogFactory/getLog ""))
user=> (.trace logger "Hello world") ;; works fine
;; Now call trace via reflection. We get the method
user=> (def mm (.getDeclaredMethod (class logger) "trace" (into-array Class [Object])))
user=> mm ;; methods says public
#object[java.lang.reflect.Method 0x59c33386 "public void org.apache.commons.logging.impl.Log4jApiLogFactory$Log4j2Log.trace(java.lang.Object)"]
;; but can't be called
user=> (.invoke mm ^Log logger (to-array ["Hello world"]))
Execution error (IllegalAccessException) at jdk.internal.reflect.Reflection/newIllegalAccessException (Reflection.java:394).
class clojure.lang.Reflector cannot access a member of class org.apache.commons.logging.impl.Log4jApiLogFactory$Log4j2Log with modifiers "public"You're checking methods on the log impl class but calling through the Log interface (I think) and those are distinct. The former may be running into module visibility access for invocation (does not prevent reflective information access)
Have you tried pulling the method from Log instead?
> You're checking methods on the log impl class but calling through the Log interface (I think) and those are distinct you mean because of the ^Log hint? I added that just to see if it helped
> Have you tried pulling the method from Log instead? no, can try that
It's a common pattern to have a public interface and a non module visible implementation class - you must then go through the public interface’s method
that seams to work
thanks!!
A couple of months ago there was a layer cake chart that illustrated code written in Clojure 1.0 and whether it survived or was replaced, and then Clojure 1.1, 1.2, etc. Where can I find it?
it's in the history paper https://clojure.org/about/history
page 26
Thanks!