Skip to content

Downloads

Current release — 1.3.0

Released 2026-08-30.

Requires a Java 25 runtime

RDF4J 6.0.0 ships Java 25 bytecode, so the JARs no longer start on JRE 21 — they fail with UnsupportedClassVersionError. Install a JRE 25+ (Temurin, Corretto, or any OpenJDK 25) before upgrading.

Output shape changes — re-resolve before upgrading

Provenance node IRIs moved out of the per-model graph into {base}provenance/…, every Backstage relationship IRI is now derived from the edge rather than a counter, and the curated model moved from graph/semantic into a new graph/model. Nothing was removed, but a consumer holding those addresses has to re-resolve. See Release Notes.

What changed in this release:

  • A fact now says which input it came from. backstage2linkedarchi puts each input file's facts in a graph named after that file, and every emitted graph is described as a prov:Bundle saying what generated it and from what. See Output serialization.
  • Every concept says which model it belongs to, via arch:inModel — so a model reassembles from the triples alone, in Turtle as well as TriG.
  • The curated model has its own graph. graph/model holds the arch:Model, its metamodel conformance, its folders and their ordering.
  • Provenance identifies its sources. A source file is identified by repository, path, commit and content digest, and a pulled catalog can name the repository it actually came from via --source-map.
  • Container images are published with a version tag (:1.3.0), not just :latest and :<commit-sha>.

Full list: Release Notes.

Verify what you downloaded:

java -jar bpmn2linkedarchi.jar --version
# bpmn2linkedarchi 1.3.0

Previous release — 1.2.0

Released 2026-07-27. First tagged release of the consolidated converters: everything before it was an overwriting 0.1.0-SNAPSHOT build of the default branch, so this is the first version you can pin. The numbering starts at 1.2.0 to stay above the 1.1.0 label that circulated on manually tagged container images.

Where to get it

Source Versioned? Token needed? Best for
GitLab Pages No — always the latest main build No Quick manual downloads, trying things out
Package Registry Yes — one immutable set per tag Yes (unless in CI) CI pipelines, reproducible builds
Docker Yes, on tags Yes, if the project is private Running without a local JRE 25

GitLab Pages — latest main build

Published as static files on GitLab Pages, no login or token required.

Note

These files track the latest main build and are overwritten by every pipeline, so they may be ahead of the release above. Three plain-text files record which build they came from — see Which build is this? below. For a fixed version, use the Package Registry.

Distribution bundle

Contains every converter (fat JAR + bin/ wrapper script), the example type-mapping and shape-config files, and the user docs.

Published under that one name only. Pages always carries the latest main build, so a version-named copy here would be a moving file wearing a fixed version's name — for an immutable per-version copy use the Package Registry. The extracted directory still carries the version, and VERSION records it.

# Download and extract
curl -fLO https://linked-archi.gitlab.io/linked-archi-tools/converters/converters/downloads/linked-archi-converters-latest.tar
tar -xf linked-archi-converters-latest.tar

# The extracted directory carries the version
export PATH="$PWD/linked-archi-converters-1.3.0/bin:$PATH"
bpmn2linkedarchi --version

Individual converter JARs

Self-contained fat JARs. Requires JRE 25+ on the target machine.

Converter Download Run
ArchiMate archimate2linkedarchi.jar java -jar archimate2linkedarchi.jar --help
BPMN bpmn2linkedarchi.jar java -jar bpmn2linkedarchi.jar --help
PlantUML plantuml2linkedarchi.jar java -jar plantuml2linkedarchi.jar --help
Structurizr / C4 structurizr2linkedarchi.jar java -jar structurizr2linkedarchi.jar --help
Backstage backstage2linkedarchi.jar java -jar backstage2linkedarchi.jar --help
LeanIX leanix2linkedarchi.jar java -jar leanix2linkedarchi.jar --help

Two more JARs ship alongside the converters and are not converters:

Tool Download Run
LeanIX pull leanix-pull.jar java -jar leanix-pull.jar --help
Backstage pull backstage-pull.jar java -jar backstage-pull.jar --help

Both fetch inputs rather than producing RDF, and both are separate commands so that fetching and converting fail, and are scheduled, independently.

leanix-pull reads a LeanIX workspace over GraphQL and writes a fact sheet export for leanix2linkedarchi to convert — see Pulling a workspace.

backstage-pull collects catalog-info.yaml files from the repositories a manifest names, recording the commit each came from, and writes the source map backstage2linkedarchi --source-map reads so a descriptor's provenance names the repository it actually came from — see Collecting a Backstage catalog.

# Example: grab the BPMN converter and run it
curl -fLO https://linked-archi.gitlab.io/linked-archi-tools/converters/converters/downloads/bpmn2linkedarchi.jar
java -jar bpmn2linkedarchi.jar convert process.bpmn \
  --base-iri https://example.org/la/ --format TRIG -o out.trig

Which build is this?

The downloads directory carries three one-line files describing the build that produced it. Each holds a single value and nothing else, so reading one needs no parser:

File Holds Example
VERSION the artifact version 1.3.0-SNAPSHOT
SOURCE_REVISION the converter commit the JARs were built from, full sha b28afe4c1d9e…
SOURCE_URL the project that commit lives in https://gitlab.com/linked-archi/…/converters

VERSION alone does not identify a build: every default-branch pipeline publishes the same -SNAPSHOT version, so two directories with identical VERSION can hold different code. SOURCE_REVISION is what distinguishes them.

The same three files are published under each Package Registry version path, so a fetch script can read them the same way from either source.

If you repackage these JARs into your own image, pass these values through so the graphs it produces can name the code that made them — see Recording provenance:

BASE_URL=https://linked-archi.gitlab.io/linked-archi-tools/converters/converters/downloads

curl -fsSLO "$BASE_URL/bpmn2linkedarchi.jar"

# Command substitution strips the trailing newline, so these are usable as-is
VERSION=$(curl -fsSL "$BASE_URL/VERSION")
SOURCE_REVISION=$(curl -fsSL "$BASE_URL/SOURCE_REVISION")
SOURCE_URL=$(curl -fsSL "$BASE_URL/SOURCE_URL")

docker build \
  --build-arg "IMAGE_VERSION=$VERSION" \
  --build-arg "SOURCE_REVISION=$SOURCE_REVISION" \
  --build-arg "SOURCE_URL=$SOURCE_URL" \
  -t my-registry/converters:"$VERSION" .

Pages is overwritten in place

A fetch that straddles a pipeline can pick up JARs from one build and a SOURCE_REVISION from the next, which would bake a sha that did not produce those JARs. For a provenance claim that has to be exact, fetch from a tagged Package Registry version, which is immutable, or pull the container image by digest and skip the repackaging entirely.

Package Registry — pinned versions

For versioned, immutable artifacts (one set per release tag), pull from the project's GitLab Package Registry. This is the recommended source for CI pipelines and reproducible builds.

A tag v1.3.0 publishes under the plain version 1.3.0, which is also the tarball name, the JAR manifest version and the Docker image tag. Default-branch builds publish under the current SNAPSHOT version and overwrite each other.

PROJECT=linked-archi%2Flinked-archi-tools%2Fconverters%2Fconverters
VERSION=1.3.0

# A single converter JAR
curl --fail -H "PRIVATE-TOKEN: $TOKEN" \
  "https://gitlab.com/api/v4/projects/$PROJECT/packages/generic/linked-archi-converters/$VERSION/bpmn2linkedarchi.jar" \
  -o bpmn2linkedarchi.jar

# The full distribution bundle
curl --fail -H "PRIVATE-TOKEN: $TOKEN" \
  "https://gitlab.com/api/v4/projects/$PROJECT/packages/generic/linked-archi-converters/$VERSION/linked-archi-converters-$VERSION.tar" \
  -o linked-archi-converters.tar

# Which commit built this version, for provenance when repackaging
curl --fail -H "PRIVATE-TOKEN: $TOKEN" \
  "https://gitlab.com/api/v4/projects/$PROJECT/packages/generic/linked-archi-converters/$VERSION/SOURCE_REVISION"

Each version path also carries SOURCE_REVISION and SOURCE_URL, the same one-line files as the Pages downloads directory. The package path already names the version, but not the commit that produced it — these do, and on a tagged version they cannot change afterwards.

Inside GitLab CI, no personal token is needed — use the built-in job token:

script:
  - 'curl --fail --header "JOB-TOKEN: $CI_JOB_TOKEN"
      "$CI_API_V4_URL/projects/<id>/packages/generic/linked-archi-converters/$VERSION/bpmn2linkedarchi.jar"
      -o bpmn2linkedarchi.jar'

Each tag also gets a GitLab Release page linking these assets.

Docker

Every converter is also bundled in a single container image, published to the GitLab Container Registry on the default branch and on tags.

Image: registry.gitlab.com/linked-archi/linked-archi-tools/converters/converters

Tag Content
:1.3.0 The 1.3.0 release (tags are published as both :1.3.0 and :v1.3.0)
:latest Most recent default-branch build
:<commit-sha> A specific commit (short SHA)

Pin the version tag for anything reproducible; :latest moves with main.

# If the project is private, authenticate first with a token / deploy token
# that has read_registry scope:
#   docker login registry.gitlab.com

docker pull registry.gitlab.com/linked-archi/linked-archi-tools/converters/converters:1.3.0

docker run --rm -v "$PWD:/work" -w /work \
  registry.gitlab.com/linked-archi/linked-archi-tools/converters/converters:1.3.0 \
  bpmn2linkedarchi convert process.bpmn --base-iri https://example.org/la/ -o out.trig

The image bundles its own Java 25 runtime, so it is the simplest option on hosts that still have JRE 21.