Fork me on GitHub
Alex Miller (Clojure team)02:08:47

Just fyi on kind of a tangent, core.rrb-vector is a Clojure contrib and the only build officially supported for those for build and deploy is the pom.xml - that has to be the primary

Alex Miller (Clojure team)02:08:08

it's ok for it to also have a deps.edn

Alex Miller (Clojure team)02:08:25

and the tool for variant classpaths is aliases


But the pom.xml is a no-op for ClojureScript, isn't it?

Alex Miller (Clojure team)02:08:03

we have other contrib libs that build a single jar usable from either

Alex Miller (Clojure team)02:08:11

data.xml, tools.reader, etc


I guess the pom.xml controls what ClojureScript source files are bundled up in there.


(tools.cli is pure .cljc so it may not be a good example for you)

Alex Miller (Clojure team)02:08:28

the trickiest part of clj/cljs contribs is testing and probably data.xml is the most advanced example out there


I will take a look at data.xml more carefully. I know pretty much all contribs do automated build and at least a subset of their tests automated with results on Do you know if any of them build and test ClojureScript code?


Ah, I see in the console log for data.xml that it does run some cljs tests using nashorn JavaScript runtime.


I should have a look at that too since the Maven build for tools.cli only does clj testing, and I do cljs testing manually via deps.edn...

Alex Miller (Clojure team)02:08:47

those are the main ones I can think of that do cljs testing

Alex Miller (Clojure team)02:08:05

"building" is really just including the cljs in the jar so not really a big deal, a bunch of contribs do that

Alex Miller (Clojure team)02:08:36

in a lib like core.async there is a manual cljs test process that we run by hand, but it's not part of ci


So that is a great lead-in to what the pom.xml should ideally do (i.e. automate ClojureScript as well as Clojure tests), and I can look into that. Definitely nicer with a working example to start from.


As far as deps.edn file goes, would it be bad to have one, if its contents conflict with what pom.xml says?

Alex Miller (Clojure team)02:08:58

many of the contribs also have project.clj files


deps.edn in a Maven-deployed JAR file should either (a) not be in the JAR, or (b) ignored by tools.deps, Maven, etc. even if one is in there?

Alex Miller (Clojure team)02:08:48

I don't think it would be in the jar file

Alex Miller (Clojure team)02:08:54

and it would be ignored by Maven

Alex Miller (Clojure team)02:08:22

there are plenty of examples to check -a bunch have deps.edn files

Alex Miller (Clojure team)02:08:41

tools.deps won't ignore it but presumably that's the point

Alex Miller (Clojure team)02:08:55

if this gets too into the weeds on contrib, I would move it to #clojure-dev


Understood. If I haven't exhausted you with questions yet, is it short to explain what happens when tools.deps follows a dependency to a git repo, and that git repo has both pom.xml and deps.edn files?


If that is involved, no worries, I can wait.


(or experiment)

Alex Miller (Clojure team)02:08:24

that's why I said it matters to tools.dep


thx. Keeping some notes separate from here for future reference.


@andy.fingerhut When building JARs, you're mostly just going to get src and the META-INF stuff (which includes a pom.xml file) but nothing else from the repo (so no deps.edn file).


When you depend on a JAR, the transitive dependencies are figured out from that embedded pom.xml file (as I found out recently with depstar!).


When you depend on a git or local repo, tools.deps will use deps.edn if present else pom.xml. If neither are present, you can tell tools.deps to "assume" deps.edn (and it treats the absence as an empty {}).


:deps/manifest :deps


Hey, when using tools.deps on a git dependency (which is a tools.deps project itself as well), can I load an alias of this dependency? The use-case is: I want to dynamically load a project using tools.deps+dynpath (up to this point I got it running), access its test/ folder and run the tests. No specific project yet, just trying some ideas.

Alex Miller (Clojure team)15:08:54

but something under consideration


I think that could be solved by adding paths and deps with resolve-deps and make-classpath then.


If I got it right, then calling (make-classpath {...} ["test"] nil) could allow that, right?

Alex Miller (Clojure team)15:08:53

need more words to understand what you mean

Alex Miller (Clojure team)15:08:06

what is "that" and "it"?


My intent of being able to run the tests from a dependency I pull dynamically as explained in the use case above.

Alex Miller (Clojure team)16:08:20

then, yes that should work

Alex Miller (Clojure team)16:08:35

you probably want to also include the source paths though I would assume


Good. Thanks for the help.


Can someone here help me to understand how I can rebuild/re-install a local dependency without quitting and restarting Spacemacs/Cider? I was originally declaring a Git dependency and then I changed my deps.edn file so that the dependency was to a local path. That is, my deps.edn started out as {:deps github-myorg/mylib {:git/url "" :sha "6c9cbfa1b1721b3d7789e6ff65a3c01065fd6c54"}} and changed to {:deps mylib {:local/root "/path/to/root/of/mylib"}}.

Alex Miller (Clojure team)18:08:38

you'll have to restart your repl to pick that up


thanks @alexmiller. I was thinking that would be necessary, but was hoping not


I have a project that depends on a library A via :local/root. Library A depends on google-cloud-monitoring depends on commons-logging. In library A, I have :exclusions [commons-logging] set on When I run clj -Stree in my top level project, I still get commons-logging/commons-logging in the tree. If I run clj -Stree in library A, I also get commons-logging. Any idea what is going on here?


Global exclusions would solve this btw ^


@kenny commons-logging is used by a lot of things -- perhaps something else is bringing it in?


Perhaps. But it is shown under

Alex Miller (Clojure team)23:08:31

where do you see it in the tree?

Alex Miller (Clojure team)23:08:13

did you try :exclusions [commons-logging/commons-logging] ?


Well, several layers deep in there


No, I can though. I thought they'd be the same.

Alex Miller (Clojure team)23:08:36

I wonder if there's a non-canonicalized matching canonicalized somewhere

kenny23:08:45 1.78.0
  javax.annotation/javax.annotation-api 1.3.2 1.78.0 0.16.1
    io.grpc/grpc-protobuf 1.21.0
      io.grpc/grpc-protobuf-lite 1.21.0 1.45.0
      io.grpc/grpc-alts 1.21.0
        org.apache.commons/commons-lang3 3.5
        io.grpc/grpc-grpclb 1.21.0 3.7.1
  io.grpc/grpc-stub 1.21.0 1.60.0 1.78.0 0.12.0 3.7.1 1.8.1 1.30.1 1.3
      io.opencensus/opencensus-contrib-http-util 0.21.0
      org.apache.httpcomponents/httpclient 4.5.8
        org.apache.httpcomponents/httpcore 4.4.11
        commons-logging/commons-logging 1.2

Alex Miller (Clojure team)23:08:09

if you can, I'd try changing the exclusion


Commenting google-cloud-monitoring shows another dep bringing it in. I guess I can follow the trail.


commons-logging/commons-logging does it


Gosh, I wonder how many other places have an exclusion that isn't qualified and it should be :thinking_face:


Wait, now commons-logging is showing up in another location in the tree.

Alex Miller (Clojure team)23:08:11

yeah, the code doesn't canonicalize the exclusions


Changing the :exclusions in a :local/root dep does not invalidate the clj cache.

Alex Miller (Clojure team)23:08:50

Yeah, that’s a known issue

Alex Miller (Clojure team)23:08:30

I have a plan to fix it but it’s a pain


Gotcha, ok. Out of curiosity, would it be possible to resolve deps in parallel?

Alex Miller (Clojure team)23:08:56

Yes, have thought about it some

Alex Miller (Clojure team)23:08:06

Generally you have most stuff in local repo already so I don’t find it critical