This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-02-01
Channels
- # announcements (3)
- # aws (1)
- # babashka (56)
- # beginners (42)
- # calva (9)
- # cider (6)
- # circleci (5)
- # clj-kondo (17)
- # cljs-experience (1)
- # cljsjs (2)
- # clojure (106)
- # clojure-australia (1)
- # clojure-europe (36)
- # clojure-germany (5)
- # clojure-italy (13)
- # clojure-nl (14)
- # clojure-spec (19)
- # clojure-uk (27)
- # clojurescript (27)
- # cursive (20)
- # datomic (24)
- # events (2)
- # fulcro (11)
- # graalvm (1)
- # jobs (6)
- # lsp (6)
- # malli (5)
- # meander (36)
- # membrane (17)
- # nbb (4)
- # nextjournal (86)
- # off-topic (18)
- # pathom (3)
- # polylith (5)
- # portal (14)
- # rdf (5)
- # re-frame (5)
- # releases (6)
- # remote-jobs (3)
- # reveal (2)
- # ring (6)
- # shadow-cljs (171)
- # tools-deps (61)
- # vim (10)
- # xtdb (6)
I was wondering: we have three server applications in our polylith repo. We’re normally building them as separate uberjars and deploying them seperately. Now we have a demo setup where it would be convenient to run all of them in one uberjar. This is quite easy to do with polylith, just add a new project and a new base and I’m done. The thing I don’t like about that though, is the duplication of the component dependencies between the different project definitions. This is a bit brittle, because people are probably going to forget adding new components also to the “all-in-one” project. I tried to add a dependency directly from “all-in-one” to “project-a” let’s say, but Poly doesn’t like that: it expects that components that are required are also specified in deps.edn
. Did anybody come up with a nice solution to prevent the duplication of the dependencies?
Hi. Ok, so when you add component x
to project-a
then you also want to make sure it is also added to the all-in-one
project? My suggestion is that you write a little program that can calculate if any brick is missing (which can be put in a new component in your workspace). By calling e.g. ws get:projects:project-a:component-names:src
and the three other variants that include base-names
and the test
source, you should be able to collect all used bricks for a project and then you can do that for all the three projects and compare it with the bricks in all-in-one
and see if you have any missing bricks. The ws
command can be executed from the code via the workspace
function that lives in the api
component of the polylith
repo (make sure you add a dependency on the https://github.com/polyfy/polylith repo, to get access to the code) . Then you can create a githook to make sure it is executed before developers commit their code.
This is of interest something we are planning to do kind of support microservice and monolithic architecture to allow us to adapt, currently we use a more monolith style but we can build with smaller projects in mind and switch if the need arises
Sounds like a good plan.