development
project mirrors the command-line
project:user
component and that we think distributing the load, by delegating to a new service, could solve the problem:development
environment? The problem here is that it contains two components that share the same user
interface. This will confuse both the classloader (if we start a REPL) and the IDE, because we now have two components using the same se.example.user
namespace in the path, which is not a desirable situation.profiles
:user
interface from the development
project and combining it with one of the two possible profiles
we get a complete development project. This allows us to work with the code from a single place, but still be able to mimic the various projects we have.default
profile (if exists) is automatically merged into the development
project, if no other profiles are selected. The name default
is set by :default-profile-name
in workspace.edn
and can be changed, but here we will leave it as it is.command-line
tool should communicate with user-service
over the wire. After some searching, we found this slacker library that allows us to use remote procedure calls in a simple way.user-api
base. user-remote
component.user
to user-remote
in deps.edn
for the command-line
project.user-service
project.user-service
.slacker
library to the base../deps.edn
.slacker
related libraries to ./deps.edn
.user-api
:slacker
library to bases/user-api/deps.edn
:user-api
paths to ./deps.edn
:slacker
related libraries to ./deps.edn
:api
namespace:core
namespace:slacker
library to the component.user
paths from ./deps.edn
.default
and remote
profiles.remote
profile in the IDE.default
profile in the REPL configuration.slacker
library to components/user-remote/deps.edn
:user
related paths from ./deps.edn
:default
and remote
profiles to ./deps.edn
:src
and test
directories. This works as profiles are only used from the development project.remote
profile in our IDE:core
namespace:interface
namespace:default
profile to Aliases
: "test,dev,build,+default"user
component from the "main" paths in ./deps.edn
and now we have to add it via a profile instead. We need the source code for the se.example.user.interface
namespace, and we have two alternatives, the user
or the user-remote
component that both use this interface. The user
component is a better default because it's simpler and only communicates via direct function calls without hitting the wire.user
with user-remote
for the command-line
project.deps.edn
for command-line
.command-line
uberjar.command-line
project:user
with user-remote
, and add the log4j
library (to get rid of warnings) in projects/command-line/deps.edn
(it's okay to keep the poly/user name, because it's also the name of the interface that both user
and user-remote
share):deps.edn
:user
component.user-api
base.aot
and uberjar
aliases.cl
alias for the user-service
.user-s
alias for the user-service
and remove the :test
keys in workspace.edn
:user-service
:remote
profile in our IDE earlier, which made the user-remote
component active. Note that this only instructs the IDE to treat user-remote
as source code:development/src/dev/lisa.clj
:hello
function, we still get:user
component into the REPL every time we start or restart the REPL. This is the recommended way of configuring the default REPL, by selecting the "simple" components that communicate with each other using direct function calls. Because of this, we should keep the "dev,test,build,+default" configuration as it is.Aliases
to "dev,test,build,+remote". This REPL will use the user-remote
component and can be used to "emulate" a production like environment.user-remote
without restarting the REPL. Open the core
namespace of the user-remote
component and select Tools > REPL > Load file in REPL
. This will replace the user
implementation with the user-remote
component, which works because both live in the same se.example.user
namespace, which is also their interface (user
).hello
function agan, we should get:info
command (+
inactivates all profiles, and makes the default
profile visible):st
, follow the same pattern as for bricks and projects except that the last "Run the tests" flag is omitted.dev.lisa
namespace, which can help us switch profiles by using a library like tools.namespace.remote
profile is included in the development
project and listed after active profiles
.user
and user-remote
in the development
project!--
in the project section.:loc
:loc
column counts the number of lines of codes under the src
directory, while (t)
counts for the test
directory.~/.polylith/config.edn
which is set to ,
by default.