Catalogs und Repositories
Überblick
OctoMesh unterscheidet für die Verwaltung von Construction Kit Model Libraries zwischen Catalogs und Repositories:
- Catalog: Ein dateibasiertes Speichersystem, das verschiedene Construction Kit Model Libraries in mehreren Versionen bereitstellt. Catalogs dienen als Quelle, aus der Bibliotheken importiert werden können.
- Repository: Eine in einer Datenbank (z. B. MongoDB) gespeicherte Sammlung von Construction Kit Model Libraries, die zusammenarbeiten. Ein Repository enthält von jeder Bibliothek genau eine Version, und alle Bibliotheken müssen logisch miteinander kompatibel sein.
Catalogs
Catalogs sind dateibasierte Speichersysteme, die Construction Kit Model Libraries zentral für OctoMesh bereitstellen. Sie können mehrere Versionen derselben Bibliothek enthalten, sodass Sie auswählen können, welche Version Sie in ein Repository importieren.
Catalog-Typen
File System Catalog
Lokale Verzeichnisstruktur, die Construction-Kit-Bibliotheksdefinitionen enthält. Geeignet für Entwicklungsumgebungen oder On-Premise-Deployments. Während des Builds ist er zugleich das Publish-Ziel und die Auflösungsquelle für voneinander abhängige Construction-Kit-Modelle, die im selben Lauf kompiliert werden.
Das Catalog-Root wird in dieser Reihenfolge aufgelöst:
OctoLocalCatalogRootPathMSBuild-Eigenschaft (oder die transiente Option-lcrvonocto-ckc) — wenn gesetzt, liegen sowohl der Catalog-Inhalt als auch dessen Cache unter diesem Root.- Repository-Konvention: Wenn das Repository
OctoRepoRootPathdefiniert (alle meshmakers-Repositories tun dies überDirectory.Build.props), verwendet der Catalog standardmäßig<repository parent>/.octo/local-catalog— ein isolierter Catalog pro Branch-/Workspace-Checkout, nach derselben Konvention wie der../nuget-Paketordner. - Fallback:
~/.octo/local-catalog(Benutzerprofil), wenn keine der beiden Möglichkeiten verfügbar ist, z. B. für Konsumenten des MsBuildTasks-Pakets ohne die meshmakers-Props-Konvention.
Auf CI-Agents setzen die Build-Pipelines OctoLocalCatalogRootPath auf $(Agent.TempDirectory)/octo-local-catalog (über die gemeinsame Vorlage update-build-number.yml), sodass jeder Pipeline-Lauf einen frischen, isolierten Catalog erhält und Feature-Branch-Builds niemals unveröffentlichte Modelle in andere Builds durchsickern lassen können.
Git Catalog
GitHub- oder andere Git-basierte Quellen für versionskontrollierten, verteilten Zugriff auf Construction-Kit-Bibliotheken. Ermöglicht Zusammenarbeit und Änderungsverfolgung über Teams hinweg.
Standardmäßig ist der meshmakers-Git-Catalog konfiguriert, verfügbar unter meshmakers.github.io.
System Libraries
Die Kern-Construction-Kit-Bibliotheken werden direkt in den Quellcode der OctoMesh-Services einkompiliert. Diese System Libraries sind ohne externe Catalog-Konfiguration automatisch verfügbar und stellen grundlegende Datentypen und Muster bereit, die von der Plattform benötigt werden.
Catalog-Struktur
Construction-Kit-Bibliotheken werden in validierter Form innerhalb der Catalogs gespeichert. Die validierte Form enthält alle Typen, Attribute, Records, Enums und Assoziationen. Catalogs können mehrere Versionen derselben Bibliothek enthalten (z. B. Industry.Energy-1.0.0, Industry.Energy-1.1.0, Industry.Energy-2.0.0).
Abhängigkeitsauflösung
Beim Import von Bibliotheken werden die Catalogs durchsucht, um Abhängigkeiten aufzulösen. Die Suchreihenfolge ist:
- Embedded System Construction Kits – In OctoMesh-Services einkompilierte, integrierte Bibliotheken
- Local File System Catalog – Benutzer- oder projektspezifische Bibliotheken
- GitHub Catalog – Gemeinsam genutzte Bibliotheken aus der konfigurierten Git-Quelle
Catalogs mit octo-ckc verwalten
Das Werkzeug octo-ckc stellt Befehle für die Arbeit mit Catalogs bereit:
Verfügbare Catalogs auflisten
octo-ckc -c GetCatalogs
Listet alle bekannten Construction-Kit-Catalogs mit ihren Namen und Beschreibungen auf.
In einen Catalog veröffentlichen
octo-ckc -c Publish -f <file> [-c <catalog>] [-r]
| Parameter | Beschreibung |
|---|---|
-f, --file | Pfad der kompilierten Construction-Kit-Modelldatei (erforderlich) |
-c, --catalog | Name des Catalogs (Standard: LocalFileSystemCatalog) |
-r, --replace | Vorhandenes Modell ersetzen, falls es bereits existiert |
-lcr, --localCatalogRoot | Root-Pfad des lokalen File System Catalogs nur für diesen Aufruf (nicht persistiert) |
Modell aus einem Catalog abrufen
octo-ckc -c Get -c <catalog> -n <name> [-f <file>]
| Parameter | Beschreibung |
|---|---|
-c, --catalog | Name des Catalogs (erforderlich) |
-n, --name | Name des abzurufenden Construction-Kit-Modells (erforderlich) |
-f, --file | Optionaler Ausgabedateipfad zum Speichern des Modells |
Modell in Catalogs suchen
octo-ckc -c Find -id <modelId>
| Parameter | Beschreibung |
|---|---|
-id, --modelId | Zu suchende Modell-ID, einschließlich Versionsbereichen (erforderlich) |
Durchsucht alle bekannten Catalogs nach dem angegebenen Modell.
Abhängigkeiten wiederherstellen
octo-ckc -c Restore -f <file> -o <outputPath> [-c <cache>]
| Parameter | Beschreibung |
|---|---|
-f, --file | Pfad der Modellkonfigurationsdatei (erforderlich) |
-o, --outputPath | Ausgabepfad für kompilierte Construction Kits (erforderlich) |
-c, --cache | Optionaler Cache-Dateipfad für abhängige Modelle |
-lcr, --localCatalogRoot | Root-Pfad des lokalen File System Catalogs nur für diesen Aufruf (nicht persistiert) |
Stellt alle Construction-Kit-Abhängigkeiten anhand einer Modellkonfigurationsdatei wieder her.
Catalog-Cache aktualisieren
octo-ckc -c RefreshCatalogCache [-c <catalog>]
| Parameter | Beschreibung |
|---|---|
-c, --catalog | Name des Catalogs (Standard: LocalFileSystemCatalog) |
Aktualisiert den Cache eines bestimmten Catalogs, indem er von der Festplatte neu geladen oder aus Remote-Quellen abgerufen wird.
octo-ckc -c RefreshAllCatalogCaches
Aktualisiert den Cache für alle bekannten Catalogs.
Repositories
Ein Repository ist eine zusammenhängende Menge von Construction Kit Model Libraries, die in einer Datenbank (etwa MongoDB) gespeichert sind. Anders als Catalogs erzwingen Repositories eine strikte Versionskompatibilität:
- Single-Version-Regel: Ein Repository enthält von jeder Model Library genau eine Version
- Versionskompatibilität: Alle Bibliotheken in einem Repository müssen logisch miteinander kompatibel sein
- Abhängigkeitskonsistenz: Bibliotheksabhängigkeiten müssen innerhalb desselben Repositorys erfüllt sein
Repository-Merkmale
| Aspekt | Beschreibung |
|---|---|
| Speicher | Datenbank (z. B. MongoDB) |
| Versionen pro Bibliothek | Genau eine |
| Kompatibilität | Alle Bibliotheken müssen zusammenarbeiten |
| Zweck | Laufzeit-Datenmodell für OctoMesh-Instanzen |
Bibliotheken importieren
Beim Import einer Construction Kit Model Library aus einem Catalog in ein Repository:
- Das System prüft, ob die Abhängigkeiten der Bibliothek erfüllt sind
- Die Versionskompatibilität mit vorhandenen Bibliotheken wird überprüft
- Existiert bereits eine andere Version der Bibliothek, muss diese aktualisiert werden, sonst schlägt der Import fehl
- Alle abhängigen Bibliotheken müssen kompatible Versionen haben
Beispiel
Ein Repository könnte Folgendes enthalten:
Repository "production"
├── System-1.0.3
├── Basic-1.0.0 (depends on System-1.0.3)
├── Industry.Energy-1.0.0 (depends on Basic-1.0.0)
└── EnergyCommunity-1.0.0 (depends on Industry.Energy-1.0.0, Basic-1.0.0)
Alle Bibliotheken bilden eine zusammenhängende Menge, in der Abhängigkeiten erfüllt und Versionen kompatibel sind.
Vergleich
| Aspekt | Catalog | Repository |
|---|---|---|
| Speicher | Dateisystem oder GitHub | Datenbank (z. B. MongoDB) |
| Mehrere Versionen | Ja | Nein (eine pro Bibliothek) |
| Zweck | Bibliotheksverteilung | Laufzeit-Datenmodell |
| Versionsbeschränkungen | Keine | Strikte Kompatibilität |
| Abhängigkeiten | Können ungelöst sein | Müssen vollständig aufgelöst sein |