Fork me on GitHub
#tools-build
<
2021-10-07
>
seancorfield03:10:00

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)

seancorfield03:10:22

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 ...}

seancorfield03:10:10

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!).

seancorfield03:10:23

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).

seancorfield03:10:06

(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)

seancorfield03:10:28

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.

seancorfield04:10:57

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.

seancorfield04:10:42

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 😞

seancorfield22:10:33

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.

seancorfield22:10:33

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.

seancorfield22:10:15

☝️: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...