Versionskonflikte

[edigonzales]

In der aktuellen Snapshot-Version werden die aktuellsten ili2c- und iox-ili-Versionen verwendet. Das führt bei mir in GRETL zu Konflikten. Ich kann das forcieren, dass die älteren verwendet werden, dann wird eventuell aber früher oder später eure Funktions-Lib nicht mehr tun (falls ihr zu neues Zeugs verwendet).

cc @ojeker wegen Natgef.

[olivergrimm]

Unser aktueller Build verwendet generell die jüngsten Versionen, auch beim Funktionsmodell selbst gehen wir aktuell auf 2.4. Das ist ein bewusster Entscheid und entspricht der Philosophie (oder unserer DNA). Wir sind der Ansicht, dass davon abweichende Builds bei Bedarf individuell realisiert werden müssten. Damit will ich nicht sagen, dass nicht wir das tun wollen, sondern dass dies aus unserer Sicht idealerweise anforderungsorientiert gemacht und ergänzt wird.

[edigonzales]

Das geht solange gut, solange es abwärtskompatibel ist. Sowohl beim Modell wie beim Code. Also eigentlich sind es zwei Konfliktherde?

Das Funktionsmodell ist 2.4. Das funktioniert mit einem zu prüfenden 2.3-Modell nicht. Plusminus kann man einfach aus der 4 ein 3 machen. Aber: Es können 2.4-Funktionen auch Datentypen enthalten, die nicht 2.3-kompatibel sind.

Code: Es funktioniert, wenn keine Klassen/Methoden verwendet werden (in den IoxPlugins), die es nur in der aktuellsten Version gibt. Bei mir kam folgender Fehler. Wobei nicht untersucht, ob es am Library-Mix lag oder wegen was neuem. Tippe auf meinen verursachten Mix, da es standalone mit illivalidator 1.13.3 funktioniert:

Info: first validation pass...
Info: /home/runner/work/gretl/gretl/gretl/src/test/resources/data/publisher/files/av_test.itf: DM01AVCH24LV95D.Liegenschaften BID=itf0
Error: ch.interlis.ili2c.metamodel.Domain.iterator()Ljava/util/Iterator;
Info: ...validation failed

ili2c war glaub 5.3.2, weil forciert. iox-ili wurde die aktuellste reingespült.

abweichende Builds bei Bedarf individuell realisiert werden müssten.

Builds direkt m.E. weniger, da der Build ja "nur" der selbstgeschriebene Funktionscode ist. Die Abhängigkeiten sind relevant.

Unser aktueller Build verwendet generell die jüngsten Versionen

"Ja aber": Ich habe auch keine Lösung, finde ich aber schon bisschen heikel. Einerseits ist es ein Plugin, im dümmsten Fall bin ich aber gezwungen die Kernkomponenten überall upzudaten, damit das Plugin funktioniert.

Erinnert mich an die Java-Versions-Diskussion :)

[olivergrimm]

Das Funktions-Modell liegt im Rahmen eines Zwischenstandes hier vor: https://github.com/sogis/p-naturgefahren-ili/blob/main/modell/GeoW_FunctionsExt_23.ili