Clojurians Log v2

I have a very similar setup to David. I used uswitch/lambada library to expose the lambda handler in the base. Then, the project configuration (`deps.edn`) decides which components go together with the lambda base. I’m using juxt/pack.alpha to generate AOT compiled jars, but I think depstar could be a better choice. I have this naming convention for the lambdas in my workspace where if the project is named, e.g. xxxx, then my Lambda base is named xxxx-lambda. Then if I have a REST api project named yyyy, then I would name its base as yyyy-rest-api. This helps me easily see bases that expose different API types.

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

thanks @furkan3ayraktar!

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