[Refactoring] Mögliche Baustellen

[edigonzales]

• Gradle-Update: Was bedeutet das? Wie viel muss in unseren build.gradle umgeschrieben werden?
• Umstellung auf Versioning-Catalog (bedingt neuere Gradle-Version ?)
• Umstellung auf Property-API / Lazy Configuration: https://docs.gradle.org/current/userguide/lazy_configuration.html -> Auswirkungen auf unsere build.gradle? Z.K. Ich hatte beim Rumspielen echt Mühe damit, weil es scheint strenger geworden zu sein bezüglich Tasks, die in das gleiche Verzeichnis schreiben (oder so). Hat vielleicht aber auch mit der Gradle-Version zu tun. Herausforderung bleibt.
• Java 11 als Runtime. Ich glaube der Gpkg-Task macht Probleme (unklar, ich dachte eher Geotools funktioniert nicht. Kann aber sein, dass das wenige, das wir verwenden funktioniert und beim Gpkg ein anderes problem ist).
• Geotools-Update: iox-wkf muss zuerst gemacht werden. Bedingt i.O. von Claude. Auf Anhiebt dünkt mich das machbar, da iox-wkf von niemand anderem ausser von GRETL verwendet wird. (oder?)
• Testing: Konsequent mit Testcontainer wo nötig und möglich. Z.B. S3 mit Localstack (wenn brauchbar)
• Testing: Heute ist das handgestrickt mit ProcessBuilder damit Docker Image Tests und Jar-Tests die gleiche Basis verwenden können. Im Prinzip steht mit Testkit (oder wie das heisst) was von Gradle selber zur Verfügung. Damit dürfte aber Docker nicht mehr funktionieren. Nicht sicher, ob ich mal eine Lösung gehabt hätte.
• Die Übergabe von dynamischen Parametern, wie z.B. DB-Urls oder Mockserver-Urls, ist fehleranfällig oder relativ komplex. Geht das einfacher?
• Testing: Publisher-Simi-Server als Testcontainer.
• Testing: junit5? Wird junit4 noch unterhalten? Wie lange noch? Oder Spock Framework?
• Build-Pipeline: Performance erhöhen. Build inkl. Tests dauert circa 24 Minuten. Circa 15 Minuten wegen Docker Tests.
• Build-Pipeline: Gesamte Logik reviewen.
• Oracle-JDBC-Chaos aufräumen: Früher war das behind closed doors. Nun ist das Jar frei verfügbar. In den build.gradle aufräumen.
• Organisation build.gradle-Dateien (inkl. integration-test.gradle): kann das vereinfacht werden. Hat eine gewisse Komplexität. Auch weil für das Docker-Image auch wieder was existiert.
• Tests: maxParallelForks > 1? Funktioniert, wenn Tests isoliert sind. Lokal brächte es etwas. Mit den normalen Github-Runnern eher wenig.
• Umstellung master -> main
• Dokumentation/Bemerkungen in build.gradle etc. bereinigen. So stimmen die Bemerkungen zur Oracle-JDBC nicht mehr.

Nachgelagert / Weiterentwicklungen:

• SQL-Tasks mittels Transaktion, d.h. erst am Ende aller Tasks committen.
• geodienste.ch-Upload-Task resp. curl-Task (für Solr-Triggering), damit curl nicht zur Laufzeit benötigt wird.
• JSON-Support in iox-wkf: Stand heute noch eher rudimentär. Nur mit Modell (?) und keine Db2json, json2db.
• Dokumentation: Referenz vs. Benutzerhandbuch? Wo liegt die Doku? Kann man mehr zum Code verlagern? Siehe z.B. Gradle DSL Doku. Diese kommt zum grössten Teil aus dem Code: https://docs.gradle.org/current/dsl/index.html Der Umbau in die Doku hingegen ist sehr mühselig mit docbook, eigenen Plugins etc. (so verstehe ich es jedenfalls). Das Resultat gefällt mir aber.

Rahmenbedingungen:

• Muss ARM64 / Apple Silicon buildable und runnable bleiben. Nicht sicher, ob buildable gilt, wegen Testcontainer und eventuell unkompatiblen Images.

[edigonzales]

• Aus Diskussion während Präsentation: Wie soll die Aufgabenverteilung / Organisation bezüglich Dockerimage sein? Alles im gleichen Repo? Muss das Dockerimage auch sämtlichte Tests durchlaufen (Anmerkung: Grundsätzlich finde ich es gut, dauert einfach sehr lange.) Fokussieren auf Besonderheiten des Images? Man kann herrlich diskutieren was genau jetzt Unit-Tests und Intergration-Tests sind.

[claeis]

Wie soll die Aufgabenverteilung / Organisation bezüglich Dockerimage sein? Alles im gleichen Repo?

Aus dem gleichen Grund wie man beim Programmieren zwei Module/Funktionen statt eines macht: weil es um orthogonal verschiedene Aspekte geht.

• Aspekt a) fachliche Funktionalität (z.B. berechne den Steuerwert)
• Aspekt b) betriebliche Funktionalität (z.B. läuft der Service?)

[edigonzales]

@claeis Bin immer noch gespalten. Ob ich eine Jar-Datei builde oder ein Docker-Image verschwimmt je länger je mehr. Oftmals wir nur noch das Docker-Image publiziert. Andererseits... siehe GRETL. Hier fände ich ne Trennung eben aus den Erfahrungen glaub wieder besser.

[claeis]

Man macht ein Docker-Image ja nicht wegen Nichts, sondern weil man etwas (m.E. betriebliches) kapseln will.

Und meistens ist dieses Etwas gross genug. Das sieht man m.E. im git-commit-Log; wenn es vorallem Commits gibt, die die Docker Config betrf. ist es gross genug, um ein getrenntes Repo zu rechtfertigen.