We aren't yet but once we finish migration we will need to

Hopefully, I'll have a nice, generic solution by then 🙂

Thank you for spending time on this!

@U04V70XH6 We’re deploying a library to S3 from Polylith using tools.build and slipset/deps-deploy. The only irritating thing so far has been that we’ve had to add our component dependency list to build.clj (`:src-dirs`) rather than the deps.edn located in the project directory.

(That could be ignorance on my part, though.)

@U0HJA5ZQT If you use my build-clj wrapper for tools.build, you will have a simpler build.clj file and you can just pass :transitive true to the jar task (in build-clj).

How are you building your pom.xml for the library?

That's something else tools.build gets "wrong" by default for Polylith-based libraries.

@U04V70XH6

(defn jar [_]
  (println "Writing pom.xml")
  (b/write-pom {:class-dir class-dir
                :lib       lib
                :version   version
                :basis     basis
                :src-dirs  src-dirs})
  (println "Copying src dirs")
  (b/copy-dir {:src-dirs   src-dirs
               :target-dir class-dir})
  (println "Creating the jar")
  (b/jar {:class-dir class-dir
          :jar-file  jar-file})
  (record-version))

How are you computing that basis? Do your libraries have external dependencies declared in the components's deps.edn files?

The issue I raised is that by default the pom.xml generated that way will not have the top-level library dependencies from the components -- only the top-level library dependencies from the projects... But you should not need to specify library dependencies in projects's deps.edn if the components's deps.edn files already contain those (unless you are deliberately overriding them with different versions).

And you're having to maintain that list of src-dirs yourself, right? My wrapper with the :transitive true option takes care of that automatically for you: it figures out the sources to include, based on the dependencies in the projects's deps.edn file.

Mmm, gotcha. Yeah, I’m including them in the project deps.

Right, so you're duplicating a bunch of stuff and having to maintain that manually. You don't need to.

For us, that's all automatic now.

Okay, I gotcha. Cool! Yeah, I hadn’t looked at that in a bit, and you’re right—I must have duplicated it to include the deps.

But will that resolve this?

(def src-dirs ["../../components/utils-cast/src"
               "../../components/bahtml/src"
               "../../components/string/src"
               "../../components/beta/src"
               "../../components/beta/resources"])

I’m actually confused by tools.build’s use of src-dirs: it appears to only include one in the POM, but needs the rest for the JAR. I’d prefer I not even need these references, even in the project’s deps.edn.

For write-pom, you should just use the projects source dir (if any).

But the basis for write-pom needs the top-level transitive deps from the components (in addition to the project) -- but you shouldn't need to duplicate any library deps and they should be in the components, if the components rely on a library (other components do not belong in components deps.edn files, just libraries).

If you use build-clj, your entire jar task would become (bb/jar {:lib lib :version version :transitive true}) followed by your call to (record-versions)

As an example of how much it simplifies things: https://github.com/seancorfield/next-jdbc/blob/develop/build.clj

(that's not a Polylith project but :transitive true would be the only difference)

Here's Polylith's build.clj (on the shell branch): https://github.com/polyfy/polylith/blob/shell/build.clj#L107 -- showing how it builds libraries.

(it only copies the pom.xml out because it wants to delete the classes folder so things are cleaned up during the build -- to match the legacy deployer behavior)

@U04V70XH6 That is all super helpful. I’m looking forward to more of the community adopting tools.build—the docs are so slim!