Hello Roman,
What do you mean that you're getting the same error? Getting the same
error with Guix Clojure or with Nix Clojure? Metabase or the test
project by Andreas?
I'm fairly confident that the problem is not caused by the S3 transport
because alot of transitive dependencies are missing from the class-path
that are not related to these libraries you cited. I was investigating
the reported class-path from within Clojure with
https://github.com/clojure/java.classpath, which is also dependency for
Metabase, so you could try it in a nREPL session.
I'm currently trying to maven-resolver-provider from 3.9 to 3.8 and
will report results, hopefully soon -- I'm new to Guix and need some
more time. If it works out, I'll try to push patches.
Thanks,
Kriss
On 10/3/24 17:48, Roman Scherer wrote:
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 <roman.sche...@burningswell.com> 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 <l...@gnu.org> writes:
Hi Andreas and Kristiyan,
Cc’ing Roman and Rostislav who are among the recent committers for this
file.
Andreas Bauer <andreas.wolfgang.ba...@gmail.com> 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 <skre...@gmail.com> 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’.
