Clojurians Log v2
polylith
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).
Nice!
Great going Sean. How many projects do you have to migrate in total? Or is the 16 all of the already?
@domparry 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.
(since I can just designate a JAR to build and a :main-class to use)
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 😐
That's inspiring. I think we are going to dedicate more focused effort on migrating to poly from now on.
1I 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.
(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 "/" %)))))))))projects, assuming each project uses depstar and has an :uberjar alias that can be invoked with -X.(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 {})))clojure.tools.deps.alpha :as t)and [clojure.tools.deps.alpha.util.dir :refer [with-dir]]
Our team has a couple of lambdas in a Polylith repo. Unfortunately it is a private one, that I cannot share here.
We have a project containing a deps.edn with depencencies and aliases.
A base with a namespace that contains the lambda entry point. The "api" of the lambda.
The base consumes components with functionality used by the lambda, just as in any other Polylith project.
To build the lambda, we use depstar and have a "compile" (or did we name it "jar"?) alias that AOT-compiles the code and builds a jar file. That file is the one we deploy to AWS.
The jar-file can be manually deployed, or (as we do) with AWS CDK ("infrastructure as code").
Hope this helps!
Cool! This will be interesting to follow 🙂
@furkan3ayraktar has several years of experience of working with AWS lambdas + Polylith. He could be a good candidate to explaining this.
Thanks!