This fails to find org.jboss.naming:jnpserver:jar:5.0.3.GA. org.immutant/messaging has the jboss repo specified in it's pom but only transitively depends on jnpserver. The the immediate dependencies of org.immutant/messaging do not specify the jboss repository.

clj -Sdeps '{:deps {org.immutant/messaging {:mvn/version "2.1.10"}}}' -Stree

@alexmiller btw, I checked up on canonicalize-deps and either it's not working or I'm misunderstanding what it's supposed to do:

(let [cfg {:deps '{clj-time {:mvn/version "0.8.0"}
                   clj-time/clj-time {:mvn/version "0.7.0"}}
           :mvn/repos mvn/standard-repos}]
  (canonicalize-deps (:deps cfg) cfg))
;; => [[clj-time #:mvn{:version "0.8.0"}]
;;     [clj-time/clj-time #:mvn{:version "0.7.0"}]]

there’s actually two different points where things get canonicalized

the other is one of the extension methods that gets called by resolve-deps, and I think that’s where this gets adjusted

I started doing this earlier in canonicalize-deps and then ended up incorporating it later in the process instead

sorry, don’t have time to look at it now

In the case of git deps, which paths of the repo get added to the classpath? Does it look at a pom file? Can you control this? E.g. also add the test dir so you can run the tests of a git dep?

git deps will detect the manifest type (deps.edn or pom.xml) and use the paths indicated

you can override it with :deps/manifest :deps or :deps/manifest :pom

I guess that’s only useful if both are present, else it will choose whichever is present?

prefers deps.edn

then pom

if neither will throw, but if you explicitly set to :deps, it is tolerant of a missing deps.edn

and just treats it as a dep with no transitive deps

in that case it chooses ["src"] as the default :paths?