# novaris-modern-parent

Migrationsziel des Novaris-Lernprojekts: dieselbe fachliche Policen-/Schadenlandschaft wie
`novaris-legacy-parent`, neu gebaut auf Spring Boot statt EJB/WebSphere, auf OpenShift
migriert. Strangler-Fig-Ansatz: der Legacy-Reactor bleibt **unveraendert** als "Vorher"-
Referenz bestehen, dieser Reactor ist das "Nachher".

Vollstaendiger Migrationsplan, Begruendung und Phasenroadmap: `docs/70-migration/`. Alle
acht Migrationsphasen (M0-M7) sind umgesetzt - M6 sind fuenf nachtraeglich
identifizierte Erweiterungen (Draft-Cleanup, Kafka-DLT, echte DB2-Anbindung, Observability,
OIDC/Keycloak, siehe `docs/70-migration/08-11*.md`), M7 ist das Frontend plus zwei real
gefundene und behobene Blocking-Bugs (siehe `docs/70-migration/12-13*.md`).

## Modulstatus

| Modul | Status | Legacy-Gegenstueck |
|---|---|---|
| `novaris-common-modern` | fertig (M0-M4) | `novaris-common-legacy` |
| `novaris-policy-core-modern` | fertig (M1-M7) | `novaris-policy-core` |
| `novaris-claims-modern` | fertig (M3-M6) | `novaris-claims-mq` |
| `novaris-notification-modern` | fertig (M3-M6) | `novaris-notification-jms` |
| `novaris-policy-web-modern-spa` | fertig (M7) | `novaris-policy-web-legacy-jsf` |
| OpenShift-Manifeste + Jenkinsfile (M5) | vorbereitet, Cluster-Verifikation offen | `novaris-policy-ear`, Legacy-Jenkinsfile |

## Zwei Versionsetappen

- **Etappe A (M1-M3):** Java 11, Spring Boot 2.7.x, `javax.*`-Namespace.
- **Etappe B (seit M4):** Java 17, Spring Boot 3.2.x, `jakarta.*`-Namespace - aktueller Stand.

Begruendung und Ergebnis des Sprungs (inkl. eines echten, unerwarteten Breaking Change):
`docs/70-migration/01-versionsstrategie.md`.

## Bauen und testen

```bash
mvn test
```

Java 17, keine externen Abhaengigkeiten fuer die Tests (H2 statt Oracle als
Default-Datenquelle, eingebetteter Kafka-Broker statt echtem Cluster) - siehe
`novaris-policy-core-modern/README.md`.

## Container-Images und OpenShift

Ein `Dockerfile` je Modul + Manifeste in `openshift/` - siehe `openshift/README.md` und
`docs/70-migration/07-openshift-und-jenkins.md` (inklusive der dort dokumentierten Grenzen:
`docker build` und eine echte Cluster-Anwendung wurden in dieser Entwicklungsumgebung
mehrfach versucht, scheiterten aber an Container-interner Netzwerk-Unzuverlaessigkeit -
ehrlich dokumentiert statt verschwiegen).

## CI/CD

Eigenstaendiges `Jenkinsfile` in diesem Verzeichnis (vier Stages local/test/qs/prod,
strukturell analog zum Legacy-`Jenkinsfile`, aber mit Podman-/Docker-Container-Image-Build und
`oc apply`/`ci/scripts/deploy-openshift.sh` statt EAR-Deploy).