Clojurians Log v2

Here's what I did:

1. I have a build base and build project housing it. Most of my build code is in the base and I have some parts in components 2. I have the base (and component dependencies) included in my dev alias so they are available in the dev repl 3. my :build alias hase the build project in its extra-deps, and has the main namespace from the build base as :ns-default

this worked fine so far

Sounds reasonable, I'll give that a try. Thanks!

Would you mind pinging back here once you do please? This bit is something I often wonder if I've overengineered.

And I'd be interested in your experience with it.

Sure! I'm tinkering now. Will report back tomorrow. I have several artifacts that must be built in a similar way, so it makes sense to parameterize the build, and more generally just treat it as any other code.

Re: overengineering: I'm just getting started with Polylith, and there is (I feel) a fair bit of plumbing that must be set up just so. But doing that forces more structure into the whole workspace, which will pay off.

> just treat it as any other code This is exactly why I put it into the poly workspace proper. Since I already have the workspace with multiple deployables (projects, executables, programs, however you call it) in it, it just didn't make sense to have build (another program) outside of that structure.

A related question: Do you import all components, bases and projects as separate modules in IntelliJ?

Not explicitly, but I think that's how Cursive does it by default. There are some important settings you'll want to double-check, see https://cursive-ide.com/userguide/polylith.html

Yeah, I've set those. I'm just puzzled about the workflow after creating new bases (for example) with poly create . Should I then "Import module" and select the new base dir? Or re-import the whole workspace (root deps.edn)?

unless you run into issues I wouldn't bother

> When Cursive syncs a polylith project, the main app and the individual components are all synced as IntelliJ modules

I think by "sync", Colin here refers to the "Refresh Clojure Deps Projects" action

Ah, I see. Just tried it, and that is indeed what happens. 👌

I can't speak to Cursive -- I use Calva -- but at work we have build.clj at the top-level and don't treat it like part of Polylith. However, that also means that we have to manually manage its dependencies "separately" too and I've been thinking about making more of it into a base and having a proper project for the build, so it's interesting to read this thread and see how others have done it. Do you still have a top-level build.clj file at all, or is it subsumed into <top-ns>.build and you just work with that instead?

I don't have a top-level build.clj, just use a namespace from the base so it's similar to <top-ns>.build at the moment. :ns-default in the build alias makes it convenient to use it.

Gotcha. That's what I assumed for the changes I'm currently making at work 🙂

I've successfully moved my build programs into the structure that you outlined, @imre. It works beautifully, thank you! I now have one mycompany.build namespace (in a build base, point 1 above) with both general functions for building jars, and more specialized functions for building the various jars (defining the lib names, target dirs, versions and so on). This namespoace can be exercised from the dev REPL (point 2 above). In the top-level deps.edn there's a :build alias with {:local/root "projects/build"} and :ns-default mycompany.build . The jar-building functions in mycompany.build are called from the command-line with clj -T:build <build-some-jar-fn>.

I don't know if it's necessary to have a build project, though. As per the Polylith docs, projects are for assembling code into artifacts - here we're just using the code in the base.

The build project seems like an unnecessary indirection. The only thing it does is specifying the Clojure version and depending on the build base. I'm now experimenting with using the base directly from :build alias, and it seems that works fine. Is there some advantage to having a project for this that I'm missing, given my very limited experience with Polylith?

I suppose it doesn't make too much difference if all your build code is in the base. I have some utility components used both by build and production code and so the project references all of them (base plus components needed). I could reference all those in the build alias too, but having them in the project makes poly check aware of them and signals if I forgot to include a component dep.

Gotcha, makes sense!

If you have projects, poly test will runs tests for each project, to exercise any code that changes -- useful if you end up with tests for your build (base), or you build depends on components that changed.

Also true!