Ludo recently merged some of my patches that I have re-submitted recently. There are 4 patches missing, that I haven't submitted again. They contain the S3 support. But it's not clear if they can be included inn Guix, because some of the artifacts are Clojure EDN files generated from AWS API docs. The code to generate them has not been published by the Clojure team. That was a blocker back in the day according to Maxim Devos. The patches are here: https://github.com/r0man/guix/commits/clojure-s3-transport/ I really should find that thread ... Roman Scherer writes: > Hi, > > I just tried this and got the same error. I'm not using the Clojure > package from Guix because the AWS S3 support has been ripped out. I use > the package from Nix. > > My guess is, this error is also because of the lacking S3 support, or if > not it will break later. The deps.edn file of Metabase contains: > > ``` > {"athena" {:url "https://s3.amazonaws.com/maven-athena"} > "redshift" {:url "https://s3.amazonaws.com/redshift-maven-repository/release"} > ;; for metabase/saml20-clj > "opensaml" {:url "https://build.shibboleth.net/nexus/content/repositories/releases/"}} > ``` > > So it's using S3 to resolve Maven dependencies. There is an open issue > for this https://issues.guix.gnu.org/53765 and I opened a duplicate of > this a while ago (which I can't find right now). Unfortunaltly this went > nowhwere. > > Roman > > Ludovic Courtès writes: > >> Hi Andreas and Kristiyan, >> >> Cc’ing Roman and Rostislav who are among the recent committers for this >> file. >> >> Andreas Bauer wrote: >> >>> Now it can be fixed with time machine: >>> >>> guix time-machine --commit=98e4bfe96f2c99daa0b66b65c1d379bb385301a8 -- guix >>> shell --pure --development --check clojure-tools openjdk coreutils >>> >>> Then in time-machine run again clojure-X:curl and the demo will work. >> >> Kristiyan Kanchev skribis: >> >>> I'm seeing issues with the project Metabase: https://github.com/metabase/metabase. When `clojure -M:run`, it fails with: >>> Execution error (ClassNotFoundException) at java.net.URLClassLoader/findClass (URLClassLoader.java:476). >>> jakarta.servlet.AsyncContext >>> >>> The problem seems to be that Clojure CLI (`clojure-tools` guix package) doesn't construct proper class path including all transitive >>> dependencies of the project. I've tried to figure out what might be causing the issue and I suspect `maven-resolver-*` packages. Clojure >>> CLI depends on `tools.deps` clojure lib, which itself depends on `maven-resolver-*`. There is a mention in the `tools.deps` changelog of >>> reverting `maven-resolver-*` libs in version 0.18.1374 with comment "Revert update of Maven resolver libs - seeing resolution >>> differences". >>> Here is the relevant commit: >>> https://github.com/clojure/tools.deps/commit/04539cd060d41a528794c04b50a6aa2293b672ce >>> >>> Up until this date, `tools.deps` lists the older versions of maven-resolver-* libs in its deps.end file. Since Guix uses the latest versions of >>> maven-resolver-* libs, I think this is causing the issue. >> >> Roman, Rostislav: does that ring a bell? >> >> Thanks, >> Ludo’.