Fork me on GitHub
#polylith
<
2021-06-26
>
seancorfield05:06:36

Started exploring the idea of migrating all our legacy artifacts into projects in our monorepo, even though we're still very early on the refactoring of the overall codebase. Looks very promising: I can just declare that the project depends on the (legacy) subproject that is the main entry point, treating it as a "base" even though it isn't in the Polylith structure (yet!). In tandem with this we're looking at replacing at least parts of our build shell script with a Clojure build.clj script of some sort, with an eye on the upcoming tools.build (that Alex talked about at clojureD) -- we're already taking advantage of being able to run multiple exec functions via -X in the latest CLI prerelease (1.10.3.882).

polylith 9
🚀 12
seancorfield07:06:35

Here's where we are now:

projects: 16   interfaces: 18
  bases:    2    components: 18
All the artifacts we build are projects now, even though they all just depend on legacy subprojects. In addition, our build shell script has pretty much gone away, along with a lot of our workspace-level deps.edn (we no longer need all the per-subproject aliases) as we've moved to a Clojure script instead.

polylith 6
🙌 3
domparry09:06:19

Great going Sean. How many projects do you have to migrate in total? Or is the 16 all of the already?

seancorfield16:06:07

@U1S4MH05T We had 14 artifacts that we built for deployment, so those are all projects now, plus development, plus a dev-only tool which I hadn't considered as a candidate for a projects entry until yesterday. So that's "everything" converted in terms of buildable artifacts as projects. But my plan is to pull apart several of our larger artifacts into smaller projects: we have multiple -main functions in our codebase and we run some of them via java -cp the.jar the.main-ns rather than java -jar the.jar, so I plan to get us away from that by adding more projects.

polylith 2
seancorfield16:06:35

(since I can just designate a JAR to build and a :main-class to use)

seancorfield16:06:42

Then I plan to break apart all those -main namespaces from our legacy projects and those will become bases. That was actually my intention when I started this work, but I got distracted by converting our build system from several shell scripts to a single Clojure script instead 😐

domparry16:06:56

That's inspiring. I think we are going to dedicate more focused effort on migrating to poly from now on.

polylith 2
seancorfield05:06:36

I suspect I'll start pulling all our our -main functions out into bases fairly soon as part of this work and, yes, more blog posts will accompany it all.

📚 9
seancorfield08:06:53

(defn uberjars [& projects]
  (doseq [p projects]
    (let [uberjar  (requiring-resolve 'hf.depstar.uberjar/build-jar)]
        (with-dir (io/file (str (System/getProperty "user.dir") "/projects/" p))
          (uberjar (-> (calc-project-basis) :aliases :uberjar :exec-args
                       ;; cater for being _above_ the project dir:
                       (update :jar #(str "projects/" p "/" %)))))))))
A function that can be run at the top of the workspace to build uberjars in projects, assuming each project uses depstar and has an :uberjar alias that can be invoked with -X.

seancorfield08:06:31

(defn- calc-project-basis []
  (let [{:keys [root-edn project-edn]} (t/find-edn-maps)
        deps  (t/merge-edns [root-edn project-edn])]
    (t/calc-basis deps {})))
(assumes clojure.tools.deps.alpha :as t)

seancorfield08:06:05

and [clojure.tools.deps.alpha.util.dir :refer [with-dir]]

tengstrand13:06:05

Cool! This will be interesting to follow 🙂