Yes -in that I’m using the tool right. No, in that my experience with leiningen is that when I build a jar file for a library, the dependencies of that library are on the classpath when the library is consumed. There are consequences to that (pedantic conflicts of transitive dependencies, etc) but at least the consumer of a lib doesn’t have to research the potentially myriad transitive deps of every lib he uses.

I feel like I’m missing something.

But maybe the issue is in the pom file.

@cch1 If you build a library JAR that you deploy to Clojars or Maven, it's only going to have the project source in it, but you need a pom.xml file for that deployment.

Right. Done that.

So you would do clojure -Spom to generate a skeleton pom.xml, then edit it so the group/artifact/version are correct.

Then depstar will pick up that pom.xml file and put it in the JAR with your source code.

Is there a difference between “install” and “mvn-deploy” w.r.t. pom file treatment by either the installer or the consumer?

(I’ve done the pom generation, and depstar does indeed include it)

I don't know what you're using for install or mvn-deploy so I can't answer that. That's not part of depstar

But when I “install” the jar to my local maven cache, consumers don’t seem to pick up the transitive deps.

You’ve helped me narrow down the issue.

I build all my libraries with depstar and deploy them to Clojars and, so far, no one has had a problem depending on them and picking up all the transitive dependencies, based on the pom.xml that is in those JAR files.

Maybe it’s an issue with install.

I use slipset/deps-deploy to put my JARs on Clojars.

I “install” locally (prior to slipset/deps-deploy ) with:

{:replace-deps {org.clojure/tools.deps.alpha {:mvn/version "0.9.816"}
                                            org.slf4j/slf4j-nop {:mvn/version "1.7.25"}}
                             :ns-default clojure.tools.cli.api
                             :exec-fn clojure.tools.cli.api/mvn-install
                             :exec-args {:jar "janus.jar"}}

But this is no longer a depstar issue for sure.

Any reason you install locally?

Just to test that the pom and jar were generated correctly before uploading to clojars. 🙂

and the ultimate test would be to consume my own dog food …. and it didn’t work.

COnfirmed that mvn-install does not install a pom file to the local maven repo…

I’ll bet that’s the root cause here.

Not sure of the “right” solution though.

As a test, I removed most of my local ~/.m2 repo and did a local install of next-jdbc.jar using the -X:deps mvn-install approach, then I removed most of my local ~/.m2 repo again and in another folder, did `clj -Sforce -Sdeps '{:deps {seancorfield/next.jdbc {:mvn/version "1.1.610"}}}' and saw it

Downloading: seancorfield/next.jdbc/1.1.610/next.jdbc-1.1.610.pom from clojars

I have seen that kind of behavior before and baffled. I am a babe in the woods when it comes to maven though.

So, yes, confirmed that -X:deps mvn-install does *not* put a POM in the repo -- but slipset/deps-deploy's install option does

Hallelujah. I copied the pom.xml generated by clj to the .m2 director (with appropriate renaming to match what I saw in other libs) and voila! it works.

Whoa!

That's the difference. So I'd say, use deps-deploy for local installs instead.

So maybe the tools.deps one is “deficient”

Agreed that seems like the right solution.

I would certainly ask Alex about it in #tools-deps

A big rabbit hole since the real goal was to deploy to clojars…. sounds like that will be easy now.

Will do.

I re-ran my test scenario above using deps-deploy install and when I that final clj -Sforce -Sdeps... it did not attempt to download the POM from Clojars -- and it correctly picked up the dependencies from the .pom in the repo.

using -X:deps mvn-install gave me this:

(! 676)-> ls -lR ~/.m2/repository/seancorfield/
total 0
drwxr-xr-x  4 sean  staff  136 Oct 19 17:15 next.jdbc

/Users/sean/.m2/repository/seancorfield//next.jdbc:
total 8
drwxr-xr-x  4 sean  staff  136 Oct 19 17:15 1.1.610
-rw-r--r--  1 sean  staff  305 Oct 19 17:15 maven-metadata-local.xml

/Users/sean/.m2/repository/seancorfield//next.jdbc/1.1.610:
total 96
-rw-r--r--  1 sean  staff    164 Oct 19 17:15 _remote.repositories
-rw-r--r--  1 sean  staff  44300 Oct 19 11:24 next.jdbc-1.1.610.jar

(! 683)-> ls -lR ~/.m2/repository/seancorfield/
total 0
drwxr-xr-x  4 sean  staff  136 Oct 19 17:18 next.jdbc

/Users/sean/.m2/repository/seancorfield//next.jdbc:
total 8
drwxr-xr-x  5 sean  staff  170 Oct 19 17:18 1.1.610
-rw-r--r--  1 sean  staff  305 Oct 19 17:18 maven-metadata-local.xml

/Users/sean/.m2/repository/seancorfield//next.jdbc/1.1.610:
total 104
-rw-r--r--  1 sean  staff    188 Oct 19 17:18 _remote.repositories
-rw-r--r--  1 sean  staff  44300 Oct 19 11:24 next.jdbc-1.1.610.jar
-rw-r--r--  1 sean  staff   1996 Oct 19 11:16 next.jdbc-1.1.610.pom

(interestingly, deps-deploy install also preserves the file timestamps too, it seems)

Yup:

-rw-r--r--   1 sean  staff  44300 Oct 19 11:24 next-jdbc.jar
-rw-r--r--   1 sean  staff   1996 Oct 19 11:16 pom.xml

That's from the original project dir.

I’ve notified Alex in #tools-deps … I’m curious to get his perspective.

Yeah, it will be interesting to hear whether it was a conscious decision or just an omission. I think some of the newer tooling around t.d.a hasn't gotten much testing yet out in the wild. I saw a bug reported against git-resolve-tags yesterday -- also something I don't think many people have tested yet. That's why it's all marked "alpha" I guess 🙂

I followed the conversation between you and Alex after the fact… specifying the pom file explicitly is a work-around for now. Thanks for your help.

Yup. We're all good: Alex said it was def. a bug and I created a JIRA ticket. I'd expect it to get fixed within a week or so. But you have a workaround for now (either specify :pom with "pom.xml", or use deps-deploy like I do)

Thanks for catching it and working with me to nail it down and repro -- good work!