lego bricks can be reasoned out more easily if they could be grouped according to domains, usages or whatever purpose.

I find it aids discoverability since you only need to look at one alphabetical list of things. We used to have a grouped hierarchy of namespaces before we moved to Polylith and it was harder to find things and think conceptually about "components" when they could be arbitrarily nested.

(we have 156 components implementing 153 interfaces at this point, plus 23 bases, and 23 projects)

The single depth also makes tool support much, much easier since there's a single, fixed pattern for checking interface usage (well there are a few patterns since interface and ifc are supported, and interfaces can also be in interface/<segment>.clj files)

I see. But since the only hints one can refer to when it comes to searching for components is name, I found one depth hierarchy sometimes lacking context. For instance, domain components (users, alarms, notifications .. etc) and util components (such as datetime, serializers, java interops) could be separated for developers for better discoverability. As an alternative I chose to use prefix, but was not much satisfied.

Should Clojure's ns always respect its enclosing directories' names? for example, even though a 'user' component is placed under 'domain' directory, its ns can choose not to contain 'domain' in its ns declaration.

In fact, what I want is as simple as being able to group components, without having to alter their namespaces.

Perhaps name your components as <domain>-<item> so you get grouping based on name within a single level? Polylith is pretty opinionated about structure.

yea right now thatss the only viable option.

Not for too long, thanks to an upcoming support for workspace(s) nesting.

@U01CC82BJKU where did you get the news? I can't find one in Github or this channel.

@U01TFN2113P See the various discussions about the 0.2.19 release -- part of the internal structure changes in the workspace data in this release is to prepare for nested workspaces in a future release.

good to hear! thanks for sharing

Here, in Slack, and in a dedicated issue as well: http://github.com/polyfy/polylith/issues/431 @U01TFN2113P

Have you read the https://cljdoc.org/d/polylith/clj-poly/0.2.18/doc/build section of the poly tool documentation? Cljdoc didn't respond now, but you can find the same page on github https://github.com/polyfy/polylith/blob/master/doc/build.adoc.

I mean to build the polylith CMD tool so that it can be packaged

just for reference worth noticing I grab the command from the ci script here https://github.com/polyfy/polylith/blob/3edb530c618f072a95ed305b816cfcead22658f3/.circleci/config.yml#L222

If you want to build the CLI tool locally, you can use the uberjar command instead of create-artifacts. The latter is used in the CI for the poly tool to first detect the changes projects since the last release and release a new version. If you try running that locally without any changes to the code, there will be no changed projects and nothing will happen. It’s not meant to be used locally. You can instead run clojure -T:build uberjar :project poly. It should generate a uberjar. You could also run clojure -T:build install :project poly and it will generate a jar file and install it to your local maven repository.

thanks @U2BDZ9JG3 that's exactly what I was after 🙂