Fork me on GitHub

Are there any known issues around depending on an artifact like this:


i.e. the only jar for the version has a -javadoc classifier

Alex Miller (Clojure team)12:09:29

What are you expecting to happen?


Hi, sorry for the late response, I raised the issue because while I can build without any issue with leiningen I couldn't make the cljdoc build (which uses tools.deps) work


This is the tools.deps {:deps {org.clojure/clojure #:mvn{:version "1.9.0"}, ml.dmlc/xgboost4j-example #:mvn{:version "0.72"}, ml.dmlc/xgboost-jvm #:mvn{:version "0.72"}, org.clojure/clojurescript #:mvn{:version "1.10.339"}, org.clojure/tools.namespace #:mvn{:version "0.2.11"}, clj-boost/clj-boost #:mvn{:version "0.0.1"}, org.clojure/java.classpath #:mvn{:version "0.2.2"}, org.clojure/data.csv #:mvn{:version "0.1.4"}, ml.dmlc/xgboost4j #:mvn{:version "0.72"}, codox/codox {:exclusions [enlive hiccup org.pegdown/pegdown], :git/url "", :sha "4b0720941083fda9643d905f0854fabea55b175f", :deps/root "codox/"}}}


It seems impossible to get the XGBoost stuff in this way. While in leiningen I have [ml.dmlc/xgboost4j "0.72" :extension "pom"] and everything's fine

Alex Miller (Clojure team)12:09:33

pom extension is not supported - what are you expecting that to do?


I'm not using it, is in cljdoc to build the package, but now I guess there's not much it can be done about it

Alex Miller (Clojure team)14:09:12

Sorry, I’m not understanding the problem. It would be very helpful to have a description of the problem, with the things needed to reproduce it, what you expect to happen, and what is actually happening. I feel like the above has half of that but it’s very confusing to me what you’re doing.


I have a dependency, the only way to get it is to use the :extension "pom" flag, I develop, build and release my library with lein, no issues. I wanted to build docs with cljdoc which uses tools.deps and the build fails because of that dependency

Alex Miller (Clojure team)14:09:48

“the only way to get it is to use the :extension "pom" flag” - why?


@alexmiller because the dependency doesn’t come with a regular .jar file — I don’t know too much about why you package libraries like this but it seems to be a thing in this case And as far as I understand nobody (using tools.deps) will be able to use @U7P0DPQ1H s library which depends on this artifact

Alex Miller (Clojure team)14:09:49

If it doesn’t have a jar, then i don’t get how it affects the classpath.

Alex Miller (Clojure team)14:09:42

I guess maybe by having deps

Alex Miller (Clojure team)14:09:32

Which I would actually expect to work

Alex Miller (Clojure team)14:09:03

If someone could file a jira in TDEPS about this, I will look at it more closely later this week


Yeah would assume that the point of this kind of artifact is usually its deps, I.e. it’s a kind of Uber-module


wont have time to file a ticket in the next few days...


My issue still reproduces after it has been marked as a duplicate of which has been marked as fixed. Can someone with access please reopen this for me?

Alex Miller (Clojure team)12:09:20

Are you using the latest release?

Alex Miller (Clojure team)12:09:28

And what is your deps.edn? There is some new syntax from TDEPS-12 with an example in the comments there.

Alex Miller (Clojure team)12:09:20

Specifically you’ll want the lib just once with a coordinate that has :classifier [“” “native”]

Alex Miller (Clojure team)12:09:23

{:deps {com.github.jnr/ffi {:mvn/version “1.2.16” :classifier [“” “native”]}}}


Am I nutty or does the example "hello.clj" example from not work until you add :paths ["."] to deps.edn ??


@bherrmann that surprises me for two reasons, one is that it should be "src", the other is that it's a default.


Where did you put hello.clj?


ok, yea. hello.clj just needs to be under "src"


my bad... I'm automating a manual process (converting and excel file) and was thinking more script minded, less software development minded (where a src sub directory is more assumed)

Alex Miller (Clojure team)14:09:09

@mkvlr I looked at this and have reopened - you’re right that this is related to TDEPS-12 but needs a bit more work

Alex Miller (Clojure team)14:09:17

but I’m not going to get to that this week


@alexmiller thanks a lot! Yes, we can work around by manually specifying it for now so no rush from us. It’s just missing to pick up the classifier when reading the pom if I understand it correctly.


I’m writing some docs on resolving dependency conflicts, is there a tools deps equivalent to lein pedantic?


thanks @alexmiller, while that works and is good to know about it implements lein-ancient it doesn’t find dependency conflicts like pedantic 🙂


-Stree helps of course

Alex Miller (Clojure team)14:09:42

there is a totally unsupported subject to removal and alteration verbose mode for tools.deps that is primarily designed to be helpful to me


oh I’ll put that in the docs then 😉

Alex Miller (Clojure team)14:09:38

definitely an area where more could be done


I moved figwheel to Jetty thinking it was a smart move to get https support and to play nicely with larger environment


but dang its prone to tricky conflicts


the way the package is divided up


when I say tricky I mean tricky for newcomers


the conflict between ring and datomic cloud is the main problem

☝️ 4

yeah I spent about 3 hrs early on trying to get Jetty (for local dev) and datomic cloud working. I switched to http-kit and it is working well so far


@U4YGF4NGM I’ve got docs on this now


published it this weekend


sorry about that


awesome! ty!


If I have {:mvn/version nil} and an :override-deps entry of {:mvn/version "1.2.3" :exclusions [foo/bar com.quux/blah]} should I expect the :exclusions from the override to be applied to the main dep?


(and what happens if there are :exclusions on both the main dep and the override?)

Alex Miller (Clojure team)21:09:26

as in replace the original (including its exclusions)


Cool. So I can rely on specifying :exclusions just once in the overrides -- that's excellent!