This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-20
Channels
- # announcements (1)
- # babashka (74)
- # beginners (84)
- # bristol-clojurians (3)
- # cider (2)
- # clara (14)
- # cljdoc (18)
- # cljsrn (7)
- # clojure (29)
- # clojure-australia (4)
- # clojure-europe (34)
- # clojure-italy (3)
- # clojure-nl (5)
- # clojure-seattle (1)
- # clojure-uk (33)
- # clojuredesign-podcast (2)
- # clojurescript (33)
- # code-reviews (17)
- # core-async (10)
- # cursive (8)
- # datomic (21)
- # depstar (45)
- # dirac (4)
- # duct (10)
- # emacs (1)
- # fulcro (8)
- # jackdaw (2)
- # jobs (1)
- # kaocha (11)
- # leiningen (2)
- # off-topic (8)
- # pathom (35)
- # pedestal (3)
- # protorepl (13)
- # rdf (39)
- # re-frame (23)
- # reagent (2)
- # releases (1)
- # remote-jobs (6)
- # reveal (2)
- # rewrite-clj (18)
- # shadow-cljs (51)
- # sim-testing (2)
- # spacemacs (2)
- # tools-deps (37)
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.
@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.
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 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.
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.
I use slipset/deps-deploy
to put my JARs on Clojars.
{: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"}}
Any reason you install locally?
Just to test that the pom and jar were generated correctly before uploading to clojars. 🙂
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
which surprised me a bit since I would have expected it to just check the local repo and find what it needed...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.
That's the difference. So I'd say, use deps-deploy
for local installs instead.
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.
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
and using deps-deploy install gave me this:
(! 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.
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!