Artifacts
We assemble our poly bricks (components and bases) in deployable projects from which we build artifacts.
The base (a project typically has a single base) acts as the runtime entry point.
The poly tool has no say in what type of artifacts you build or how you build them.
Some artifact examples are:
-
REST APIs
-
Lambda functions
-
Command line tools
Libraries
A library is different than other types of artifacts. It does not need a base since clients talk through its interface directly.
Instead, you can create an api component that exposes the functionality of your library.
A good example is the clj-poly library that includes an api component.
Caveats on Publishing Multiple Libraries
If you want to publish more than one library from your workspace, you must build all library artifacts from the same revision of your workspace sources and ensure they all use the same versioning pattern.
We recommend a naming convention of {libfamily}-{libname}-{version}.jar.
For version 1.2.3 of libnames foo and bar under libfamily thingorama, you’d build:
-
thingorama-bar-1.2.3.jar -
thingorama-foo-1.2.3.jar
Including a lib family makes it easier to find/sort libraries and makes it clear they belong to the same family of libraries.
The burden of ensuring no version mismatches occur when using multiple libraries from a family of libraries falls on the user of those libraries.
For example, a user may directly reference thingorama-foo-1.2.3.jar, but suppose some other library they depend on references thingorama-bar-1.0.0.jar.
It is up to the user to ensure they bring in the compatible thingorama-bar-1.2.3.jar.
Another possible approach is to build a single artifact for the lib family that includes all libraries:
-
thingorama-1.2.3.jar
Issue 212 explores the problems of isolating libraries that share components. See Sean Corfield’s comments for an excellent explanation of the issue.
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close