bug#73432: clojure package is broken

[Kristiyan Kanchev <skrechy@gmail.com>]

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.scherer@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 <ludo@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.bauer@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 <skrechy@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’.