This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-07
Channels
- # babashka (30)
- # beginners (49)
- # calva (22)
- # cider (9)
- # clara (2)
- # clj-commons (1)
- # cljdoc (1)
- # clojars (7)
- # clojure (153)
- # clojure-australia (2)
- # clojure-europe (45)
- # clojure-italy (3)
- # clojure-losangeles (1)
- # clojure-nl (17)
- # clojure-portugal (3)
- # clojure-uk (6)
- # clojurescript (21)
- # conjure (4)
- # copenhagen-clojurians (5)
- # cryogen (3)
- # cursive (19)
- # datahike (14)
- # datascript (4)
- # datomic (9)
- # events (5)
- # fulcro (23)
- # graalvm (1)
- # gratitude (4)
- # helix (2)
- # holy-lambda (5)
- # improve-getting-started (2)
- # jobs (10)
- # kaocha (1)
- # leiningen (1)
- # liquid (8)
- # membrane (81)
- # off-topic (88)
- # polylith (29)
- # quil (1)
- # reitit (2)
- # remote-jobs (8)
- # reveal (8)
- # sci (1)
- # shadow-cljs (14)
- # specter (4)
- # sql (5)
- # tools-build (11)
- # tools-deps (5)
I'm working on a PR to convert Polylith's build process over from depstar
to tools.build
(directly, not via my build-clj
). Building uberjars is "easy". Build library JARs is trickier: in Polylith, projects are built from "stubs" that pull in all of their components via :local/root
and those components declare their own external deps. The project's deps.edn
may specify some external deps but mostly they come from components -- so they are "transitive top-level" stuff. I have it working but it feels a bit clunky and I'm wondering if there are easier ways to do what I'm trying to do... (in a thread)
To get the right dependencies in pom.xml
, I create a basis, walk :libs
to find libs that have poly/*
libs in the :dependents
(and also have :mvn/version
) and then compute a new basis with those (top-level transitive) deps as :extra {:deps ...}
Then I update the :libs
from that basis to have just :mvn/version
style libs (so that write-pom
doesn't complain about skipping coordinates for all the :local/root
deps!).
And the copy-dir
step takes the :classpath-roots
from that basis and filters just the directories (which should be the src
and resources
for the project itself plus all the src
/`resources` from all the :local/root
deps as well).
(this last part is essentially the default behavior of depstar
when building JAR files, but you can tell it to just use :paths
instead -- which is sort of the "default" recipe if you follow the tools.build
guide)
Confirming that I'm on the right track with creating a basis with the "1st-level" deps (top-of-the-transitive deps) for write-pom
would be good -- that part felt really clunky.
I realized after I posted this that I need to solve this in more general terms for anyone trying to build library JARs from Polylith projects.
depstar
gets it wrong -- it copies the transitive :local/root
source etc OK but it doesn't bring across those 1st-level external deps into pom.xml
😞
io.github.seancorfield/build-clj {:git/tag "v0.5.1" :git/sha "dc121d6"}
now supports a :transitive true
option on the jar
task that attempts to address the Polylith use case: it "lifts" top-level deps out of local source components so they end up in the generated pom.xml
file, and it also knows to copy those source components into the JAR "automatically" by adjusting the :src-dirs
. It also "hides" those source components from write-pom
so it doesn't complain "skipping coordinate" for non-Maven dependencies.
io.github.seancorfield/build-clj {:git/tag "v0.5.1" :git/sha "dc121d6"}
now supports a :transitive true
option on the jar
task that attempts to address the Polylith use case: it "lifts" top-level deps out of local source components so they end up in the generated pom.xml
file, and it also knows to copy those source components into the JAR "automatically" by adjusting the :src-dirs
. It also "hides" those source components from write-pom
so it doesn't complain "skipping coordinate" for non-Maven dependencies.
☝️:skin-tone-2: Note that if you are working with git deps in your code, building a pom.xml
and JAR file that you want to publish is going to be "problematic" no matter how you approach this: users depending on published JARs (on Maven/Clojars) have no way to resolve such dependencies. depstar
sort of "cheated" here and just treated them like :local/root
deps so they ended up copied into your JAR but had a caveat in the documentation about problems that can occur with libraries that bundle other namespaces from git deps and/or licensing/distribution issues. If you're using git deps, you're pretty much required to use deps.edn
and have your users depend on your project via git deps as well...