Q for @tengstrand I think: as we're migrating code around into the Polylith structure, we have new (Polylith) namespaces like ws.<brick>.whatever
and we also have some legacy ws.<subproject>.whatever
namespaces -- and today I moved some code into Polylith structure that requires some of those legacy nses... and got
Error 107: Missing components in the development project for these interfaces: billing, google-search-cli, messaging
Error 107: Missing components in the worldsingles project for these interfaces: billing, google-search-cli, messaging
Am I right in surmising that Polylith is going to consider ws.<subproject>.whatever
as being something that should be a brick in Polylith even tho' it exists outside in a legacy library?(on the assumption that I'm correct, I'm just going to migrate more of those legacy nses into components
but it just means this current piece of refactoring got substantially bigger!)
@seancorfield I couldn’t reproduced all your problems, but I have tried to fix them anyway. The changes are pushed to the issue-66
branch together with other fixes that I was working on. It should fix your 107 error
. Try it out to see if you have any remaining problems.
Thanks, I'll update the poly
tool to that latest SHA and I'll let you know if I run into any issues on Monday when I'm back at work!
Confirmed that I don't get the 107 error now on code that refers to brick-like nses that aren't Polylith interfaces.
info
and test :dev :all
both seem to work correctly too.
Sounds great.
Yes, it looks like you are right. The right behaviour should be that it only considers namespaces inside the components
directory as interfaces. I can have a look at this tomorrow and try fix it.
Thanks!
One other thing I tripped over during my refactoring marathon was this NPE:
#error {
:cause Cannot invoke "Object.toString()" because "s" is null
:via
[{:type java.lang.NullPointerException
:message Cannot invoke "Object.toString()" because "s" is null
:at [clojure.string$ends_with_QMARK_ invokeStatic string.clj 370]}]
:trace
[[clojure.string$ends_with_QMARK_ invokeStatic string.clj 370]
[clojure.string$ends_with_QMARK_ invoke string.clj 366]
[polylith.clj.core.deps.project_brick_deps$test_QMARK_ invokeStatic project_brick_deps.clj 80]
[polylith.clj.core.deps.project_brick_deps$test_QMARK_ invoke project_brick_deps.clj 79]
[clojure.core$complement$fn__5687 invoke core.clj 1443]
[clojure.core$filter$fn__5912 invoke core.clj 2821]
[clojure.lang.LazySeq sval LazySeq.java 42]
[clojure.lang.LazySeq seq LazySeq.java 51]
[clojure.lang.RT seq RT.java 535]
[clojure.core$seq__5420 invokeStatic core.clj 139]
[clojure.core$filter$fn__5912 invoke core.clj 2813]
[clojure.lang.LazySeq sval LazySeq.java 42]
[clojure.lang.LazySeq seq LazySeq.java 51]
[clojure.lang.RT seq RT.java 535]
[clojure.core$seq__5420 invokeStatic core.clj 139]
[clojure.core$sort invokeStatic core.clj 3101]
[clojure.core$sort_by invokeStatic core.clj 3107]
[clojure.core$sort_by invokeStatic core.clj 3107]
[clojure.core$sort_by invoke core.clj 3107]
[polylith.clj.core.deps.project_brick_deps$source_deps invokeStatic project_brick_deps.clj 127]
This can happen if a component's namespace doesn't match its filepath -- it would be nice if the code could be a bit more robust about that and perhaps at least give a better exception, indicating what file or brick it was trying to analyze?Update on our migration:
projects: 16 interfaces: 23
bases: 3 components: 23
Three of those "interfaces" are just migrated legacy namespaces, that haven't yet been refactored into implementations (and interfaces). That's Monday's work, while my teammate is taking Independence Day off 🙂The tool reads components from disk https://github.com/polyfy/polylith/blob/90ca45583036425ccabe932c9517cec34475ba93/components/workspace-clj/src/polylith/clj/core/workspace_clj/components_from_disk.clj#L31 so I guess you now have 23 directories under the components
directory?
Right, we have 23 components
now, but the ws.messaging.sdk
namespace that was referenced in one of those components (actually in a bases
entry I think it was) lived under a wsmessaging-sdk
legacy subproject: wsmessaging-sdk/src/ws/messaging/sdk.clj
which, of course, Polylith doesn't see -- so as far as its concerned, some Polylith code in bases/batch-jobs/src/ws/batch_jobs/messages.clj
is trying to reference a brick that doesn't exist (because it's in one of the 40 legacy subprojects). That legacy code has namespaces that start with worldsingles
(old code) and ws
(newer code) and then I picked ws
as the top ns for the Polylith code, not realizing it might "conflict".