Fachlicher Kern
Hybrid Infrastructure
Verteilte Systeme mit AWS Cloud, VM, Bare Metal, On-Premise und Dedicated Hosting.
Zentrale Versionen und Dependency-Management fuer alle Laufzeitbereiche
Interne Ports, Commands, Events und DTOs zwischen Bounded Contexts
Bare-Metal Dateisystemadapter fuer Batch-Importe und Exporte
Dedicated-Hosting SOAP Adapter fuer Partner- oder Alt-Systeme
Konfigurationsmodell fuer AWS, VM, Bare Metal, On-Prem und Dedicated Hosting
Dedicated-Hosting Deployment mit Provider-Grenzen und SFTP/SOAP
Zusammenfuehrendes Beispiel, das Domains, Adapter und Deployments verbindet
Oeffnen
Dieser Master enthaelt jetzt ein direkt ausfuehrbares Maven-Modul runnable-smoke.
Hybrid Infrastructure
Wie Anwendungen in unterschiedlichen Betriebsumgebungen gedacht werden.
Verschiedene Infrastrukturprofile für dieselbe fachliche Anwendung.
Du erkennst Zweck, Ablauf, Modulgrenzen und Betriebsbezug dieses Masters.
Welche Geschäftsentscheidung wird hier unterstützt und welche Daten müssen nachvollziehbar bleiben?
Welche Module sind wirklich Fachkern und welche sind nur Adapter, Runtime oder Infrastruktur?
Die zwei SVGs trennen bewusst Fachlichkeit und Technik. Dadurch sieht man, ob ein Thema wirklich fachlich ist oder nur eine technische Umsetzungsschicht darstellt.
Öffne RUNNABLE.html oder nutze den Smoke-Start im jeweiligen Workspace.
Wo vorhanden, ergänzen Spring Boot oder Jakarta eine echte Runtime. Smoke bleibt der robuste Minimalstart.
Bei Container-Mastern helfen Compose, Kubernetes und OpenShift-Profile beim Betriebsverständnis.
mvn -q -pl runnable-smoke -am package exec:java
Diese Links führen aus dem Lehrbuch in die eigentliche Projektstruktur.
mvn-ws-aws-vm-bm/api-adminAdministrative API fuer Betrieb, Replay, Diagnose und manuelle Korrektur
ApiAdminModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.ApiAdminFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/api-restREST API Schicht fuer synchrone Consumer
ApiRestModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.ApiRestFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/enterprise-applicationZusammenfuehrendes Beispiel, das Domains, Adapter und Deployments verbindet
EnterpriseApplicationModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.EnterpriseApplicationFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/worker-schedulerWorker fuer Batch, Retry, Replay und Dead-Letter-Verarbeitung
WorkerSchedulerModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.WorkerSchedulerFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/adapter-baremetal-filesBare-Metal Dateisystemadapter fuer Batch-Importe und Exporte
AdapterBaremetalFilesModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.AdapterBaremetalFilesFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/adapter-dedicated-sftpSFTP Adapter fuer dediziertes Hosting und B2B-Dateiaustausch
AdapterDedicatedSftpModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.AdapterDedicatedSftpFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/adapter-dedicated-soapDedicated-Hosting SOAP Adapter fuer Partner- oder Alt-Systeme
AdapterDedicatedSoapModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.AdapterDedicatedSoapFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/adapter-aws-rdsAWS RDS Adapter fuer Cloud-Datenbankzugriff
AdapterAwsRdsModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.AdapterAwsRdsFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/adapter-aws-s3AWS S3 Adapter fuer Dokumente, Rechnungs-PDFs und Archivdaten
AdapterAwsS3ModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.AdapterAwsS3Flow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/adapter-onprem-oracleOn-Prem Oracle Adapter inklusive Stored-Procedure-Grenze
AdapterOnpremOracleModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.AdapterOnpremOracleFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/adapter-vm-postgresVM-Hosting PostgreSQL Adapter fuer klassische VM-Deployments
AdapterVmPostgresModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.AdapterVmPostgresFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/deployment-awsIaC-nahe AWS Deployment-Dokumentation und Parameterobjekte
DeploymentAwsModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.DeploymentAwsFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/deployment-baremetalDeployment-Modell fuer Bare-Metal, Systemd und lokale Volumes
DeploymentBaremetalModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.DeploymentBaremetalFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/deployment-dedicatedDedicated-Hosting Deployment mit Provider-Grenzen und SFTP/SOAP
DeploymentDedicatedModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.DeploymentDedicatedFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/deployment-onpremOn-Prem Deployment mit Firewall, MQ, Oracle und internen Netzen
DeploymentOnpremModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.DeploymentOnpremFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/deployment-vmDeployment-Modell fuer klassische VMs und Reverse Proxies
DeploymentVmModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.DeploymentVmFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/billing-domainRechnungs-Domain mit Billing-Entscheidungen und Payment-Port
BillingDomainModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.BillingDomainFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/cqrs-readmodelRead-Model-Projektionen fuer schnelle Abfragen
CqrsReadmodelModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.CqrsReadmodelFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/customer-domainKunden-Domain mit Profil, Segment und Compliance-Hinweisen
CustomerDomainModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.CustomerDomainFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/inventory-domainBestands-Domain mit Reservierung, Freigabe und Kompensation
InventoryDomainModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.InventoryDomainFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/order-domainAuftrags-Domain mit Aggregates, Policies und Domain Events
OrderDomainModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.OrderDomainFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/pricing-domainPreisfindung, Rabattregeln und Entscheidungsstrategie
PricingDomainModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.PricingDomainFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/shipping-domainVersandentscheidung, Carrier-Auswahl und Zustellstatus
ShippingDomainModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.ShippingDomainFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/infra-configKonfigurationsmodell fuer AWS, VM, Bare Metal, On-Prem und Dedicated Hosting
InfraConfigModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.InfraConfigFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/platform-bomZentrale Versionen und Dependency-Management fuer alle Laufzeitbereiche
PlatformBomModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.PlatformBomFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/adapter-aws-sqsAWS SQS/SNS Adapter fuer Cloud-Messaging
AdapterAwsSqsModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.AdapterAwsSqsFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/adapter-onprem-mqOn-Prem IBM MQ / JMS Adapter fuer Legacy-Integration
AdapterOnpremMqModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.AdapterOnpremMqFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/integration-eventsKanonenform der Integrationsereignisse fuer Kafka, SQS oder MQ
IntegrationEventsModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.IntegrationEventsFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/outbox-coreTransaktionale Outbox als Kernmechanismus fuer robuste Event-Ausleitung
OutboxCoreModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.OutboxCoreFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/saga-coreSaga-Orchestrierung fuer Order-to-Cash ueber mehrere Systeme
SagaCoreModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.SagaCoreFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/infra-observabilityLogging, Metrics, Tracing und Korrelations-IDs
InfraObservabilityModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.InfraObservabilityFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/infra-securitySecurity-Modul fuer Token, Service-to-Service und Secret-Abstraktion
InfraSecurityModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.InfraSecurityFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/enterprise-contractsInterne Ports, Commands, Events und DTOs zwischen Bounded Contexts
EnterpriseContractsModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.EnterpriseContractsFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/runnable-smokeDieses Modul macht den Workspace sofort ausfuehrbar.
mvn -q -pl runnable-smoke -am package exec:javaDer Smoke-Run fuehrt einen kompakten Enterprise-Ablauf aus: Order validieren, Inventory reservieren, Payment autorisieren, Outbox-Event erzeugen und Deployment-Bereitschaft pruefen.
mvn-ws-aws-vm-bm/testing-architectureArchitekturtests fuer Dependency-Regeln und Schichtgrenzen
TestingArchitectureModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.TestingArchitectureFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/testing-chaosChaos- und Failure-Szenarien fuer Netz, Queue, DB und Filesystem
TestingChaosModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.TestingChaosFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/testing-contractContract Tests und Schema-Kompatibilitaet
TestingContractModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.TestingContractFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bmOeffne diesen Ordner als Maven-Projekt. Startpunkt ist pom.xml. Details stehen in PROJECTS.html und in den Modul-READMEs.
mvn-ws-aws-vm-bm/migration-data-syncDatenmigration, CDC, Dual-Write-Vermeidung und Reconciliation
MigrationDataSyncModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.MigrationDataSyncFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/migration-stranglerStrangler-Fig-Migrationspfad von Legacy zu modularen Services
MigrationStranglerModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.MigrationStranglerFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/ops-runbookBetriebsablaeufe, Alarme, Playbooks und Eskalationspfade
OpsRunbookModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.OpsRunbookFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
mvn-ws-aws-vm-bm/shared-kernelGemeinsame Value Objects, Fehlerobjekte, IDs und Zeitmodell
SharedKernelModuleGuide: beschreibt Aufgabe, Risiko und Ablauf.SharedKernelFlow: Ablaufmodell fuer technische Zielumgebungen, falls vorhanden.Dieses Modul ist bewusst klein, damit Codex oder Claude Code es phasenweise erweitern kann: zuerst Tests und Ports, danach Adapter, danach Observability, danach Failure-Szenarien.
Stand: 2026-07-07
Master 4 steigert die bisherigen Maven-Master-Projekte in Richtung verteilte Enterprise-Systemlandschaft. Der Schwerpunkt liegt nicht nur auf Code, sondern auf Infrastrukturgrenzen: AWS Cloud, klassische VMs, Bare Metal, On-Premise, Dedicated Hosting und VM-Hosting.
Es zeigt, wie ein moderner modularer Java-Enterprise-Workspace so geschnitten wird, dass Fachlogik stabil bleibt und technische Zielumgebungen austauschbar werden. Die Module demonstrieren DDD, Hexagonal Architecture, Outbox, Saga, CQRS, Adapter, Anti-Corruption Layer, Deployment-Modelle, Observability, Security und Failure-Tests.
1. Fachliche Bounded Contexts verstehen: Order, Billing, Inventory, Customer, Pricing, Shipping.
2. Ports und Contracts definieren.
3. Integrationsmuster ergaenzen: Outbox, Saga, CQRS, Events.
4. Adapter fuer AWS, VM, Bare Metal, On-Premise und Dedicated Hosting anbinden.
5. Deployment- und Betriebsmodelle dokumentieren.
6. Failure-Szenarien, Security und Observability testen.
7. Mit Codex oder Claude Code phasenweise erweitern, ohne Zielbild zu verlieren.
mvn-ws-aws-vm-bm/pom.xml in IntelliJ oder VS Code oeffnen.docs/project-descriptions.html lesen.docs/ai-build-phases.html verwenden.Siehe RUNNABLE.md und RUNNABLE.html. Jeder Workspace enthaelt ein Modul runnable-smoke mit Startskripten.
<span class="ok">Runnable-Ergaenzung</span>
Dieser Master enthaelt jetzt ein eigenes Maven-Modul runnable-smoke. Damit ist nicht nur Dokumentation vorhanden, sondern ein direkt ausfuehrbarer fachlicher Ablauf.
mvn-ws-aws-vm-bm: cd mvn-ws-aws-vm-bm && mvn -q -pl runnable-smoke -am package exec:javarun-smoke.bat im Workspace starten../run-smoke.sh im Workspace starten.Der Ablauf simuliert eine echte Enterprise-Kette:
AWS, OpenShift, IBM MQ, Oracle, SFTP, Spring/Jakarta Runtime und Bare-Metal-Adapter brauchen reale Infrastruktur oder Container. Der Smoke-Runner ist bewusst lokal und ohne externe Infrastruktur startbar. Die produktnahen Module bleiben Maven-Module mit POMs, Beschreibungen und Pattern-Kommentaren; der Smoke-Runner ist der schnelle Nachweis, dass der Workspace ausfuehrbar ist.
1. mvn -q -pl runnable-smoke -am package exec:java
2. Danach gesamtes Projekt bauen: mvn clean package
3. Dann einzelne Runtime-Module starten, z. B. Spring Boot oder OpenShift-Deployment.