Dependencies and kamelets

The hub resolves every jar of a version once, when it builds the version. Agents never download anything from Maven, so a site needs no route to Maven Central, no build tool and no Java download. Two agents on one version run the same jars.

Camel components#

A component your routes use by URI, such as sql:, ftp: or kafka:, is resolved by itself. List a component in integration.yaml only when the routes don’t show it, for example one a bean uses:

name: erp-invoice-export
version: 1.0.0
dependencies:
  - camel:jdbc
  - mvn:com.microsoft.sqlserver:mssql-jdbc:12.8.1.jre11

Other libraries#

A library from a Maven repository is a coordinate in dependencies, written mvn:group:artifact:version, as mvn:com.microsoft.sqlserver:mssql-jdbc:12.8.1.jre11 above. camel.jbang.dependencies in application.properties works too, and the build uses it.

A jar that is in no repository goes into the folder itself, for example in libs/. Every jar in the folder is on the classpath, with no size limit. The CLI uploads a large jar once and the agents fetch it once, not again for every version.

Maven repositories#

Integrations never name a repository. Where the builder fetches from is the platform’s configuration, set when the hub is installed: a list of Maven repositories, with their credentials kept as secrets. An installation that lists none fetches from Maven Central and from Atlassian’s public repository, which has the client Camel’s Jira component needs.

An air-gapped hub uses a single mirror and no Maven Central: its weikio-backend init line adds --maven-repository internal=https://maven.example.internal/repository/all,mirror and --no-maven-central. Builds on both Camel lines work behind such a mirror with no internet access. Air-gapped installations has the whole setup.

Kamelets#

A kamelet comes from one of four places. When two have the same name, the first in this order wins:

1. The integration’s folder: any *.kamelet.yaml in the folder, which the integration uses without listing it.
2. The platform: the five kamelets every installation ships, weikio-log, weikio-event-sink and weikio-event-source for channels, and entitystore-sink and entitystore-source for the entity store. A project kamelet can’t use one of their names.
3. The project: shared kamelets of the project, which an integration lists in integration.yaml as kamelets: [erp-paging-source].
4. Camel’s catalog: the kamelets of the catalog version pinned to the integration’s Camel line.

$ weikio get kamelets --project finance

The list has the project’s shared kamelets and the five platform kamelets. Its SHADOWS column marks a shared kamelet with the name of a catalog kamelet, and USED BY lists the versions that use each one. The Kamelets section of a project’s page in the admin UI shows the same, with each platform kamelet’s YAML as the platform ships it.

Kamelets for a run outside the platform#

weikio kamelets pull writes the project’s shared kamelets and the platform’s into a folder, with local stand-ins for the four that need an agent’s link to the hub:

$ weikio kamelets pull ./kamelets --project finance

It then prints the camel run line that uses them, which you run in the integration’s folder when the platform is out of reach. While the platform is reachable, weikio dev run does all of this for you.