1 Using External Artifacts (another module)
This tutorial shows how to use a component/service defined in another module.
There are two common patterns:
- Remote dependency (versioned): the module is downloaded into your module cache.
- Local dependency (filesystem or
.vendor): used during development without publishing.
The DSL import mechanism is the same in both cases: you import a package path and then reference the artifact.
1.1 Add the dependency in kumori.mod.json
Example: depend on a module (aliased) and pin a version.
Typical command to create this entry:
1.1.1 Remote dependency from a GitHub URL
If your dependency is hosted in GitHub, you can depend on it directly using its module path (for example github.com/<org>/<repo>).
Example kumori.mod.json using a GitHub module path:
Then download it:
Once downloaded, imports use the alias prefix:
1.2 Import the dependency package in your Kumori DSL
When you use an alias, you import using the alias prefix:
This imports the service package from the kumori.examples/dependency module. In practice, everything under the service/ folder in that module is now accessible under the service package.
1.3 Reference the external artifact from a deployment
This deployment targets an artifact defined in the imported package (service.EchoServer).
1.4 Local development alternatives
1.4.1 Local dependency (absolute path)
You can add a local module by pointing requires[].target to an absolute path (recommended to also set an alias). See Dependency Management.
1.4.2 .vendor directory
You can place a module under a .vendor/ folder at the root of your module so kdsl can resolve it without downloading. See Dependency Management.
1.5 Notes
- Imports reference packages, not whole repositories. If your dependency exports artifacts from a package like
service/, import that package. - If you later remove the dependency, remember to remove/update imports that use its alias.