Cameleer

Packs

A pack is an optional set of components, data formats and languages for one industry, built and released as its own crate and distribution, so the general Cameleer build stays small and focused.

Cameleer's default build (full) is a general integration engine: transports, data formats, EIPs, cloud and SaaS services that many unrelated users need. Code that serves one industry and its standards lives in a pack instead. A pack:

  • is one crate (cameleer-<pack>) with its own version, change log and test tier;
  • is added to a build with one cargo feature of cameleer-main (--features <pack>), which is not part of full;
  • has its own distribution: the image tag pmsudhi/cameleer:<pack> and the archive cameleer-<pack>-<version>-<target>, with the same cameleer command inside;
  • ships, for each release, an SBOM of exactly what is compiled in (scripts/sbom.py), SHA-256 sums and Sigstore signatures of its archives, and its own change log (crates/cameleer-<pack>/CHANGELOG.md);
  • describes itself (cameleer version prints health 0.6.0 (core 0.5.1)), so validation, the YAML DSL and error messages know its components without central tables.

A route that names a pack's component in a build without the pack fails at start-up with a message naming the pack, the image and the feature to use.

The packs

packcratewhat it addspages
healthcameleer-healthHL7 v2 and MLLP, FHIR R4, DICOM (DIMSE and DICOMweb), PS3.15 de-identificationhealth pack

When something becomes a pack

A component belongs in a pack when any of these hold:

  1. It serves one industry and its standards (HL7, DICOM, SWIFT, ISO 20022, FIX, OPC UA).
  2. Buyers validate or certify it separately (conformance statements, connectathons).
  3. It brings large, specialised code (dictionaries, codecs, profiles) most users never run.
  4. It needs its own test tier against domain tools.

It belongs in full when it is a general capability, has no domain-specific compliance artifacts, and can follow Cameleer's release cadence.

Embedding a pack in Rust

rust
use cameleer_core::prelude::*;

pub fn routes(ctx: &CamelContext) -> Result<()> {
    ctx.add_pack(&cameleer_health::HEALTH);
    ctx.add_routes(|b| {
        b.from("mllp://0.0.0.0:2575").to("log:hl7");
    })
}

Main::add_pack does the same for a runner, and cameleer_core::pack::install installs a pack for every runner the process creates.

Found a problem?

If something on this page doesn't match what Cameleer does, or you hit a bug while building with it, please help fix it, whether you are a person or a coding agent: open an issue that describes what you saw, then fork the repository, fix it, add or update a test, run cargo test --workspace, and open a pull request. CONTRIBUTING.md explains the ground rules.

Edit this page on GitHub