This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-29
Channels
- # announcements (1)
- # babashka (15)
- # beginners (37)
- # calva (94)
- # cider (3)
- # clj-kondo (17)
- # cljsrn (2)
- # clojure (45)
- # clojure-europe (39)
- # clojure-germany (1)
- # clojure-norway (2)
- # clojurescript (16)
- # component (18)
- # conjure (1)
- # cursive (13)
- # datalevin (3)
- # datomic (12)
- # docker (2)
- # duct (5)
- # eastwood (2)
- # emacs (4)
- # events (8)
- # fulcro (8)
- # inf-clojure (5)
- # kaocha (8)
- # lsp (24)
- # malli (11)
- # meander (3)
- # off-topic (19)
- # polylith (11)
- # remote-jobs (4)
- # sci (61)
- # shadow-cljs (9)
- # spacemacs (34)
- # sql (10)
- # tools-deps (27)
- # xtdb (10)
Do you include the other project as a :local/root dep? In that case, the resulting classpath for running the tests will be the union of the both projects. So, it won’t be isolated to the project running the tests anymore. Can you share a little bit more context? I would like to understand where the need comes from.
Sure, so it's to do with the test-runner example implementation 🙂 and especially dogfooding it.
check the projects here: https://github.com/imrekoszo/polylith-kaocha/tree/master/projects
and by default, it invokes commands from the kaocha-wrapper
project in the classloader of the project under test, so projects under test should have kaocha-wrapper
on their classpaths
(this is documented at https://github.com/imrekoszo/polylith-kaocha#usage btw)
Now, the example
project demonstrates how you'd use this in a polylith workspace, and as a result, it has a test-time dependency on, well, the component wrapped by the kaocha-wrapper
project, but also all of that component's in-workspace dependencies, which are only collected in the kaocha-wrapper
project itself
I think this could be a rare valid case for using it the way you use 😄. Good that poly tool didn’t have a check for that!