Der Projektrahmen (Scaffold)

Worum es geht

Ein neues CDMS-Projekt fängst du nicht mit einem leeren Ordner an. Der Hub gibt dir einen Projektrahmen (englisch Scaffold, „Baugerüst“): ein ZIP mit POM, Start-Klasse, Konfiguration und dem aktuellen Modell. Den entpackst du, baust einmal, und die Anwendung läuft.

Was genau im Rahmen steht, hängt von ein paar Einstellungen am System im Hub ab: Mit welcher Datenbank arbeitet es? Braucht es Anmeldung? Läuft CIAS mit im selben Prozess? Jede Einstellung ist ein Zweig, der Abhängigkeiten, Konfiguration und manchmal Klassen hinzufügt.

So kommst du zum Rahmen

Was im ZIP steht

katalog/
├── pom.xml                         ← Parent cdms-app-parent, Abhängigkeiten je Zweig
├── README.md                       ← Bauen, Starten, alle Umgebungsvariablen
├── cdms-generator.properties       ← Zugang zum Hub für den Build (Secret leer)
├── .env.example                    ← Laufzeitvariablen: Datenbank, Mandantenmodus, CIAS …
├── .gitignore
├── .cache/                         ← das Modell als YAML, damit der erste Build offline geht
│   ├── system.yaml
│   └── models.yaml …
└── src/
    ├── main/java/com/codamai/shop/katalog/
    │   ├── Start.java              ← Spring-Boot-Start-Klasse
    │   └── config/                 ← nur bei CIAS EMBEDDED: drei Verdrahtungsklassen
    ├── main/resources/application.yaml
    └── test/java/…/TenantContextArchitectureTest.java   ← nur mit Anmeldung (OIDC)

Die Maven-Koordinaten leitet der Hub aus den Namen ab. Aus dem Projekt „Shop“ und dem System „Katalog“ wird groupId com.codamai.shop, artifactId katalog und das Basispaket com.codamai.shop.katalog.

Die Zweige

Die Einstellungen stehen am System im Hub. Der Build liest sie später aus .cache/system.yaml. Maven- oder Spring-Properties schalten die Zweige nicht.

flowchart TD
    A{"authentication"} -- "NONE" --> N["keine Anmeldung<br/>CIAS ist immer NONE"]
    A -- "OIDC" --> O["+ cias-authentication<br/>+ Architekturtest<br/>+ CIAS_ISSUER, CIAS_CLIENT …"]
    O --> C{"cias"}
    C -- "REMOTE" --> R["+ cias-tenancy-client<br/>CIAS läuft als eigener Service"]
    C -- "EMBEDDED" --> E["+ cias-tenancy, cias-user,<br/>cias-authorization, cias-iam-keycloak<br/>+ Block codamai.cias<br/>+ 3 Klassen unter config/"]
    C -- "NONE" --> X["kein CIAS-Mandantendienst"]
    D{"database"} -- "MYSQL" --> D1["mysql-connector-j"]
    D -- "MARIADB" --> D2["mariadb-java-client"]
    S{"storage"} -- "FILESYSTEM" --> S1["+ cdms-localfs-storage<br/>+ basePath /files/"]
    S -- "NONE" --> S0["keine Dateien"]
    M{"monitoring"} -- "ACTUATOR" --> M1["+ Prometheus, AOP<br/>+ Metriken und Probes auf 8081"]
    M -- "NONE" --> M0["nur Actuator-Grundausstattung<br/>auf 8081"]
    U{"ein Modell auditiert?"} -- "ja" --> U1["+ hibernate-envers"]

Ob die Anwendung einen oder viele Mandanten bedient, ist kein Zweig des Rahmens. Das entscheidet zur Laufzeit CODAMAI_PERSISTENCE_TENANT_MODE (SINGLE oder MULTI), siehe Single- oder Multi-Tenant.

Ein Beispiel

<parent>
  <groupId>com.codamai.cdms</groupId>
  <artifactId>cdms-app-parent</artifactId>
</parent>
<properties>
  <cdms.main.class>com.codamai.shop.katalog.Start</cdms.main.class>
  <cdms.generator.fetch.skip>false</cdms.generator.fetch.skip>
</properties>
<dependencies>
  <!-- cdms-managed:dependencies:start -->
  … Kern: cdms-rest-api, cdms-system-layer, cdms-database …
  hibernate-envers               ← Auditing
  mysql-connector-j              ← database: MYSQL
  cdms-localfs-storage           ← storage: FILESYSTEM
  cias-authentication            ← authentication: OIDC
  micrometer-registry-prometheus ← monitoring: ACTUATOR
  cias-tenancy-client            ← cias: REMOTE
  <!-- cdms-managed:dependencies:end -->
</dependencies>

spring:
  application: { name: katalog }
  threads: { virtual: { enabled: true } }
codamai:
  cdms:
    api: { createReadMode: STRICT }
    persistence:                         ← storage: FILESYSTEM
      file:
        basePath: ${CODAMAI_CDMS_PERSISTENCE_FILE_BASE_PATH:/files/}
management:
  server: { port: 8081 }
  endpoints: { web: { exposure: { include: health, info, metrics, prometheus } } }   ← monitoring: ACTUATOR

Einmal erzeugt, danach deins

Was passiert mit den Dateien, wenn du später baust oder den Rahmen erneut herunterlädst?

Zwei Konsequenzen:

• Einen Zweig nachträglich ändern (etwa storage auf FILESYSTEM) wirkt beim nächsten Build auf die POM: Die Abhängigkeit kommt hinzu, abgewählte fliegen raus. Die passende Konfiguration in application.yaml und .env trägst du selbst nach. Das README eines frischen Rahmens zeigt dir, was dort stehen muss.
• Ein neuer Download ist ein neues ZIP. Es wird nichts mit deinem Projekt zusammengeführt. Nimm dir daraus, was du brauchst.

Die POM-Pflege schaltest du mit CODEGEN_POM_GENERATE=false ab.

Fallen