Deps doesn't support scopes (I would encourage you instead to make aliases corresponding to different classpath scenarios)

In Maven, scopes are modifiers that say whether a dep should be included in different classpath scenarios (compile time, run time, test time, and dep publishing time, roughly)

I would have to look at that code for a long while to understand it but it doesn't seem to understand how deps deals with classifiers either

Thanks! There were no classifiers in the vector I was converting.

@U0ETXRFEW I'm not sure if you've looked yet but clj-new can convert leiningen templates to deps.edn and it might have an already fleshed out version of this https://github.com/seancorfield/clj-new

The project is created with clj-new, from a Leiningen template, but I didn't see an option to convert it.

ohhhh I see

hmmm

I thought it automatically converted it

my mistake

It is quite hard to do, given all the things that can be going on in a Leiningen project.

Sorry, poor Slack etiquette, lol.

I didn’t know that also applied to the OP.

clojure.java.data.builder

https://github.com/clojure/java.data

> I would prefer to use just one approach, preferably the most flexible You should stick to interop then, it's the most flexible one. java.data has a bunch of assumptions that must hold true for it to work on a particular builder class. In the case of the error above it assumes that there's a no-arg constructor of the nested class Builder. And seems like it's not the case since you get NoSuchMethodException com.foo.MyJavaObject$Builder.<init>().

@jmckitrick Per the java.data README: > :builder-props -- properties used to construct and initialize an instance of the builder class; defaults to an empty hash map; may have :clojure.java.data/constructor as metadata to provide constructor arguments for the builder instance,

Oh wow… I might give that a try.

LMK if you have problems with it (I'm the maintainer). The :builder-props stuff could do with more extensive tests. The :clojure.java.data/constructor metadata approach has more tests around it.

I’ve not done much with metadata… so I need to attach metadata to the :builder-props map?

:builder-props (with-meta {} {:clojure.java.data/constructor [the ctr args]}) is what I think it's suggesting. It's been a while since I last messed with builders.

The value -- the hash map -- lists the properties to be added to the builder (once it is created). The metadata provides a vector of values that are passed to the builder's constructor.

I remember having a hard time finding good examples of builders with constructors in the Java standard library to write tests based on! 🙂

I’m glad I asked… I was going to start with the ^ operator/special char/whatever lol

:builder-props ^{:clojure.java.data/constructor [the ctr args]} {} would work too. I just find with-meta a bit easier to read for constructing values at runtime.

It looks like I need an instance now, so is it safe to say TheClass$Builder is what I need?

Given that’s the pattern I’m seeing throughout the SDK, of course.

I think that worked!~

And no, I did not need a builder. Now I have to make sure I got back what I expect 😉

Are this SDK's docs publicly accessible?

If the pattern is always an inner class Builder then you specify the outer class and let b/to-java figure it out (modulo constructor args above).

See https://github.com/clojure/java.data/blob/master/src/test/clojure/clojure/java/data/builder_test.clj#L16 -- it can figure out things for java.util.Locale without any options (first test), if you want to construct the builder object yourself and pass that in that's like test #3 (again, no options). Then tests #2 and #4 are for those two cases but with the options specified explicitly (they just happen to be the defaults).

Hope that clarifies things @jmckitrick?

@U04V70XH6 https://github.com/square/square-java-sdk/blob/master/src/main/java/com/squareup/square/models/OrderLineItem.java

My code is about half and half right now… some pure java interop, the rest using to-java with a builder successfully.

And yes, thanks for the help! I’ll tinker around with both approaches and pick one

Oh that is one nasty, nasty Java class -- yikes!

Glad I’m not the only one that feels that way, lol.

You can run minio on your own hardware and use the s3 api with cognitect's aws api

And if you already have an endpoint and a function that returns you the models by making a GitHub API request, you can just wrap it with an LRU or any other cache with a TTL (assuming you don't restart your server often).

@UK0810AQ2 Thanks for the recommendation any suggestions on something with a smaller footprint?

@U2FRKM4TW Thanks! Do you know a good way to store 80 - 300 megabyte responses with this strategy? It would have to be on disk I think, as RAM is quite limited at the moment.

There's https://github.com/shriphani/fort-knox but I haven't used it myself. There can be other libraries like that - your web search is as good as mine. ;)

Thanks! I have been searching around quite a bit the past week. A lot of resources use some very outdated tools and dependencies, making it harder to evaluate. And sadly I don’t have the capacity to take over and maintain. Mostly wondering if someone has had some explicit opinions about this by chance.

> very outdated tools and dependencies How do you determine whether something is outdated?

I’m sorry but that feels like a needlessly loaded question, not sure if that was your intent.

People often say that something is outdated because that something hasn't been updated in years. In the Clojure world, that often means that the library is stable and perfectly covers its scope - there's simply no more work to be done. That may or may not be the case with fort-knox that I linked above.

I totally understand. Have been using Clojure for eight years : ) Developed a little bit of an eye for figuring out which projects are in what category.

Thanks for your suggestions

thanks! are you on github?

Might be worth gathering folks in #clojure-ukraine for this? I don't know if that channel is intended to be multi-lingual (some geo channels here try hard to remain native language only).

@U053XQP4S has a few criticisms of how they're implemented. Revolving mostly around not being able to fork continuations, iirc

¯\(ツ)/¯

first class continuation support is a non-goal

virtual threads are also not serializable, which is required to solve @U4EMCR2BG’s problem IIUC

> first class continuation support is a non-goal it was an explicit goal in the first place, they removed it from scope afterwards