@hlolli, for now, you have to have (set! *warn-on-reflection* true) in each source file. I think it's a good habit to get into.

how would a subdirectory fit with git/url, thinking of https://github.com/bhauman/rebel-readline/tree/master/rebel-readline

you can specify :deps/root as a subdir in which to find deps.edn/pom.xml in the context of a git lib

doesn't look like that project needs that though? there's a deps example in the readme

Is there a way to add clojure$slim (slim classifier) as a dependency and exclude the clojure dependency that comes with tools.deps ? Adding clojure$slim to deps.edn results in both clojure and clojure$slim to be on the classpath. Looks like a consequence of the recent classifier change ?

Ah, because it comes in from the "system" deps.edn, that's interesting.

I guess the original :classifier design was better for this case.

no not possible right now. Classifier deps really are treated as separate deps and because Clojure is included by default, there is no way to remove it

Hadn’t ever thought of this re slim (almost no one uses it)

is there a way to determine a proper “groupId” from a deps.edn? not really right?

You mean for deps or for the project itself?

for the project itself

then, no

not super important, I’m just writing a utility to add a dep to a project via command line. ran into where: - plum add org.clojure/clojure "1.10.0" appends org.clojure/clojure {:mvn/version "1.10.0"} - plum add "some-long-sha" right now adds as

clojure/clojure {:git/url "" :sha "some-long-sha"}

the pragmatic thing to do would be to check for a pom.xml in the repo, I suppose. or just not worry about it

well using clojure as a git dep like that won't work (as it's half java and must be compiled into an artifact)

ah, fair point

I think the problem exists still as: I want to use the latest version on git of a library that I previously was consuming through maven. with my naive approach, a user might end up with two different identifiers in their deps.edn for the same lib

which, btw, what would the behavior be in that case? last one wins?

right now, it will error I think

it is, however, actually possible to resolve as maven artifacts include their git commit info at build time, making it possible to resolve the "newer" one via git commit comparison

I have not actually done that work yet, but have done enough research to believe it's feasible

ah neat. thanks for the info!

Yesterday I was asking about adding a self-signed SSL cert with tools.deps, and I did some research on it. I'm on NixOS, which is a functional / immutable OS, and as such its Java trust store is also immutable (read-only), so I can't just imperatively add the cert to the trust store using keytool. Unfortunately right now there's not a configuration option in NixOS to do this either. Am I SOL? https://stackoverflow.com/a/49423656/2015090