Fork me on GitHub

I’m setting : And I’m getting a Anybody know how to fix this? Relevant line is :jvm-opts ["-Dclerk.resource_manifest={\"/js/viewer.js\" \"\"}"]

Alex Miller (Clojure team)12:03:52

You probably need different embedded escaping/quoting on windows

Alex Miller (Clojure team)12:03:44

That opt gets put into a .jvm file in .cpcache, then pulled out of the file and put on the command line, where you might need “”” around the embedded opts


embedded opts is the edn map, ie the value of the prop? tried various things so far without sucess


was able to get CI green by switching to bb clojure though cc @U04V15CAJ


Hi! Basic question here. I understand I can get the classpath from the top level :deps with clj -Spath. Also I can get the classpath from an alias with clj -Spath -A:my-alias, and can merge these with clj -Spath -A:my-alias1:my-alias2. How can I merge the classpath from the top level :deps with a classpath from an alias?

Alex Miller (Clojure team)12:03:48

Depending what's in the alias that is what you get - aliases modify the deps classpath. Can you give more detail about what's in the aliases, what you get, and what you want?


Thanks! Considering this deps.edn:

{:deps    {dep/dep-root {:local/root "dep-root"}}
 :aliases {:my-alias1 {:deps {dep/dep-1 {:local/root "dep-1"}}}
           :my-alias2 {:deps {dep/dep-2 {:local/root "dep-2"}}}}}
When I’m running this clj -Spath -A:my-alias1:my-alias2, I can get a classpath with dep-1 and dep-2. I would like to get a classpath which has dep/dep-root and eg dep/dep-1


@UGSM2S2CS Use :extra-deps in your aliases instead of :deps. The former is additive. The latter is not.


Thanks! In that way, can I get a classpath with the deps only from the alias?


No. You'd need two versions of the alias, I think, one with :extra-deps and one with :replace-deps (or just :deps, but I think the former is clearer).


I guess my question would be: Why? What problem are you really trying to solve?


Perhaps there's a better approach...


You could have :deps {} and then under :aliases have :default {:extra-deps {dep/dep-root ...}} etc and explicitly specify the :default alias when you need those "root" deps.


yes, that’s what I ended up with, it works. [well. I have an ancient Java project using fairly complex ant build with xdoclet/ejb2/custom codegen/etc where the classpath is hardcoded into the build files in various places using only local jars. I wanted to start to use some Clojure here. I didn’t want to/cant replace the whole build and I don’t want to duplicate the dependencies, so I figured that in the ant config wherever a custom classpath is used, i outsource to deps.edn with an alias and call clj -Spath -A:alias from ant to calculate the classpath.]


Is there a way to have :override-deps at the top level of my deps.edn file? It seems like it only works when it's put inside an alias? I'm trying to override Netty dependency versions (ultimately I'd like to use the Netty BOM) but for now I can just write out each dependency. But I'd prefer not to have all of our clojure commands have to include a -A:defaults alias on every command. It feels like it would be quite easy for people to accidentally get the wrong Netty version.

Alex Miller (Clojure team)16:03:38

no, that's not a feature

Alex Miller (Clojure team)16:03:51

if you're trying to override the version of a transitive dep, you can add :exclusions to the top-level dep, then add the transitive dep at the top with whatever version you want

Alex Miller (Clojure team)16:03:44

lmk if that doesn't make sense


> if you’re trying to override the version of a transitive dep, you can add :exclusions to the top-level dep, then add the transitive dep at the top with whatever version you want


If this isn’t the problem :override-deps is meant to solve, what problem is it meant to solve?

Alex Miller (Clojure team)16:03:50

it's meant to solve that problem when you apply an alias

Alex Miller (Clojure team)16:03:05

that is, a conditional override

Alex Miller (Clojure team)16:03:22

if I'm reading the original request right, the goal is non-conditional override


There are a bunch of different libraries all with dependencies on various Netty components. I want to specify that if any of them pull in any of the Netty dependencies they should get the version I selected, without actually adding a dependency on any extra Netty JARs that aren't needed

Alex Miller (Clojure team)16:03:10

yeah, so there is no place to put that right now - you need to exclude on each top-level dep that includes those transitive deps


i.e. if our Redis library adds a new dependency on netty-buffer in a new version, I want to have already specified which version of netty-buffer will get pulled in, without actually including it in the JAR

Alex Miller (Clojure team)16:03:34

this is something that's been requested (global exclusions / global overrides)

Alex Miller (Clojure team)16:03:31

still haven't decided how this should best be done in deps.edn


FWIW @U051KLSJF we ourselves just eat the annoyance of having a required alias


it’s a far better world to live in than exclusion wack-a-mole to address every CVE

Alex Miller (Clojure team)16:03:20

I read that ask question as being slightly different (managed deps being - what dep should I use if version is not supplied)

Alex Miller (Clojure team)16:03:48

vs force the version to be something regardless of what transitive deps use


:managed-dependencies in Leiningen provides overrides for version resolution. I don't think it relies on the version not being provided in the main :dependencies vector, but that is a related feature


That’s my understanding also, and what I used it for when using lein.


I think it’s a direct analog to maven/pom dependencyManagement

Alex Miller (Clojure team)16:03:07

well, I may misunderstand either maven's dependencyManagement or lein's expression of it but I think of managed deps as default versions that can be overridden


all of these kind of combine the tasks of “override” and “default”


> 1. It does not actually introduce any dependencies to your project. It only says, "hey leiningen, if you encounter one of these dependencies later, here are the versions that you should fall back to if the version numbers aren't explicitly specified."


I think this means if the version number isn't explicitly specified in your :dependencies file. Which could either be you included the dependency with no version number, or it was a transitive dependency


It does in fact prefer :managed-dependencies versions to those of transitive deps, because the effect is seen in the resulting classpath. This is why this is perfect for addressing CVEs


or, at least better than exclusions + add a false direct dep

Alex Miller (Clojure team)16:03:12

well, I'll think about it more and maybe look at it Friday, thx for the poke

👍 2