Java
, Kotlin
and Clojure
where the latter is the "main" language we use to build our artifacts from. The first thing to remember is to have different names of the top namespaces so that we don't run into name conflicts. In this example, we would end up with top namespaces like: com.mycompany.java
, com.mycompany.kotlin
and com.mycompany.clojure
.java.jar
andkotlin.jar
.def/defn/defmacro
definitions for both components. If any of them don’t implement the full set, then the tool will complain when running the check
, info
or test
command.user
and user-remote
components implement the user
interface. The components live in two separate directories, under the components
directory, and both use the se.example.user
namespace but with different implementations in their core
namespace:command-line
project that contains the user
component, but then we “swap” (at compile time) to the user-remote
component, by specifying the source directory of user-remote
instead of user
in projects/command-line/deps.edn
. This is described in detail in the Profile section of the tool documentation.http-api
and mq-api
), can I easily configure the build to produce a single artifact, that includes both bases?deps.edn
configuration file for the project, e.g.: {:deps {poly/http-api {:local/root “../../bases/http-api/src”} poly/mq-api {:local/root “../../bases/mq-api/src”} ... }
You can put any combination of components and bases in a project and build a single artifact out of it. We don’t support switching components at run-time. If you need polymorphism, then you can solve it by using multi-methods to switch between two different components.import-vars
macro is kind of cool, but we have decided to keep it as it is. The main reason is that consistency and simplicity have a great value to us. Using a macro could have been an alternative if it solved the whole problem, but unfortunately, we will end up with a mix of this macro and explicitly declared functions, which is less consistent and adds complexity. By making the def/defn/defmacro
statements explicit in the interface namespace(s) we also get a lot of flexibility, see the end of the interface section of the tool documentation.