#126: Update gradle to version 6.9.4

[Saela]

Das Update auf Gradle 6.9.4 hat einige Changes mit sich gebracht. Hier eine Liste der wichtigsten Änderungen:

• Annotationen z.B. @input dürfen nur noch auf Getter gesetzt werden. Deshalb mussten alle Custom Tasks mit Gettern und Settern versehen werden.
• Es ist nicht mehr erlaubt @optional ohne @input oder @OutputFile etc. zu benutzen. An bestimmten Stellen musste @optional durch @internal ersetzt werden (z.B. Publisher.java => getPublishedRegions()). An anderen musste eine Kombination von @internal und @nullable gesetzt werden.
• @InputFile und @InputFiles werden strenger validiert. Es wird nun geprüft ob das File existiert. Es hatte einige Tasks, die bei nicht existierenden Files ein neues generiert haben. Dort musste @InputFile durch @input ersetzt werden. @input prüft nicht ob der Inhalt vorhanden ist oder nicht.
• Connector.java und Endpoint.java müssen Serializable implementieren, damit Gradle den Cache korrekt aufbauen kann.
• Ein Connector Objekt kann nun nicht mehr mittels ['db', 'dbuser', 'pw'] automatisch gemappt werden. Es musste ein alternativer Setter geschrieben werden, der eine Liste von Values annimmt und dann den Connector erstellt. Siehe z.b. GpkgExport.java. Das könnte man mittels Utils Funktion noch schöner lösen. Aktuell ist es etwas viel duplizierter Code.
• Properties vom Typ ListProperty haben NullPointerException ausgelöst, wenn diese initial auf NULL gesetzt wurden. Einige wurden bereits mit getProject().getObjects().listProperty(String.class) initialisiert, daher machte eine Harmonisierung sowieso Sinn.

Daneben gab es noch einige weitere, kleinere Anpassungen. Die Hauptarbeit musste jedoch in den Tasks gemacht werden.

[Saela]

@edigonzales Ich konnte heute nun endlich das Update auf Gradle 6.9.4 fertigstellen. Ein paar letzte Knacknüsse haben das etwas verzögert. 😅 Bitte schau dir den PR doch an. Ich habe im PR Beschrieb eine Zusammenfassung der wichtigsten Änderungen gemacht.

[edigonzales]

Ist das eine von Gradle bereitgestellte Abhängigkeit? Was macht das genau? Und warum nur in dieser Klasse? In anderen Klassen, wo Gretllogger verwendet wird, braucht es transient nicht.

[Saela]

@edigonzales Nice catch. :) Der Import konnte entfernt werden, ich hatte zuerst probiert transient als Annotation zu benutzen. Das geht aber nur in Kotlin. Ich habe vergessen den Import wieder zu entfernen.😅

Transient ist ein Java Keyword, welches einem Objekt, welches Serializable implementiert (hier Connector.java) sagt, dass das mit transient markierte Property nicht serialisiert werden soll. Das hat grundsätzlich nichts mit dem GretlLogger an sich zu tun, sondern hängt mit dem Connector Objekt zusammen. Wir verwenden z.B. in CsvExport.java ein Connector Objekt als Taskinput. Damit Gradle den Cache korrekt aufbauen kann, um zu sehen, ob sich Objekte verändert haben zwischen zwei Runs, muss alles serialisierbar sein. Gradle wirft einen Fehler, wenn Connector.java das Serializable Interface nicht implementiert. Der GretlLogger ist ansonsten nicht Teil eines Objektes, welches als Taskinput verwendet wird, daher benötigt es nicht an jeder Stelle wo der GretlLogger vorkommt das transient Keyword.

Warum ich die zwei Properties im Connector als transient markiert habe: Beim GretlLogger macht es aus meiner Sicht keinen Sinn diesen zu serialisieren. Der Status des Objektes wird durch den Logger nicht beeinflusst. Das Connection Objekt (Connection dbConnection) kann ich nicht serialisierbar machen, da es sich um eine Klasse handelt, die von Java zur Verfügung gestellt wird. Spielt hier aber auch keine Rolle, da sich die Connection in Abhängigkeit von dbUri, dbUser und dbPassword verändert und wir Änderungen also schon tracken.

Anmerkung zum Logger: Dieser wird im Connector gar nicht benötigt. Könnte man diesen auch einfach entfernen?

[edigonzales]

• Es ist nicht mehr erlaubt @optional ohne @input oder @OutputFile etc. zu benutzen. An bestimmten Stellen musste @optional durch @internal ersetzt werden (z.B. Publisher.java => getPublishedRegions()). An anderen musste eine Kombination von @internal und @nullable gesetzt werden.

Versteht man da die Logik? @optional mit @internal ersetzen, dünkt mich komisch. Da ich dachte, dass @internal schon was anderes aussagt, als optional.

• @InputFile und @InputFiles werden strenger validiert. Es wird nun geprüft ob das File existiert. Es hatte einige Tasks, die bei nicht existierenden Files ein neues generiert haben. Dort musste @InputFile durch @input ersetzt werden. @input prüft nicht ob der Inhalt vorhanden ist oder nicht.

Das hat keine für uns relevanten Auswirkungen, dass es nicht mehr @InputFile ist, nehme ich an? Und das müssten optionale Parameter gewesen sein, oder?

• Ein Connector Objekt kann nun nicht mehr mittels ['db', 'dbuser', 'pw'] automatisch gemappt werden. Es musste ein alternativer Setter geschrieben werden, der eine Liste von Values annimmt und dann den Connector erstellt. Siehe z.b. GpkgExport.java. Das könnte man mittels Utils Funktion noch schöner lösen. Aktuell ist es etwas viel duplizierter Code.

Ja, wenn es jetzt in jedem DB-Task vorkommt. Können wir noch diskutieren.

[Saela]

@optional muss neu mit z.B. @input kombiniert werden (https://docs.gradle.org/current/javadoc/org/gradle/api/tasks/Optional.html). Ich habe dieses Property mit @internal markiert, da aus meiner Sicht @input hier nicht passt. Das Property wird immer auf Basis anderer Properties (Regions/Region) gesetzt. Für den Up-To-Date Check ist es daher nicht nötig, dieses auch noch zu berücksichtigen, da es sich gezwungenermassen ändert, sobald sich Region oder Regions auch ändert.

@edigonzales

[Saela]

• Es ist nicht mehr erlaubt @optional ohne @input oder @OutputFile etc. zu benutzen. An bestimmten Stellen musste @optional durch @internal ersetzt werden (z.B. Publisher.java => getPublishedRegions()). An anderen musste eine Kombination von @internal und @nullable gesetzt werden.

Versteht man da die Logik? @optional mit @internal ersetzen, dünkt mich komisch. Da ich dachte, dass @internal schon was anderes aussagt, als optional.

Ich habe dir im Publisher.java File direkt einen Kommentar diesbezüglich gemacht und bin alle Stellen mit @internal nochmals durchgegangen. Bei einigen war es möglich @input zu setzen, da habe ich wohl nicht genug gut geschaut, ob das Property auch von extern gesetzt werden können soll.

• @InputFile und @InputFiles werden strenger validiert. Es wird nun geprüft ob das File existiert. Es hatte einige Tasks, die bei nicht existierenden Files ein neues generiert haben. Dort musste @InputFile durch @input ersetzt werden. @input prüft nicht ob der Inhalt vorhanden ist oder nicht.

Das hat keine für uns relevanten Auswirkungen, dass es nicht mehr @InputFile ist, nehme ich an? Und das müssten optionale Parameter gewesen sein, oder?

Also Auswirkungen hat es schon. @InputFile ist speziell auf Files ausgerichtet und kann z.B. auch schauen ob sich der Inhalt geändert hat. Das ist vorallem auch für inkrementelle Builds interessant. @input kann das nicht, dort wird nur geschaut, ob sich das File noch am selben Ort befindet oder nicht. Zitat aus der Dokumentation von Gradle:

This will cause the task to be considered out-of-date when the file path or contents have changed.
Note: To make the task dependent on the file's location but not its contents, expose the path of the file as an [Input] property instead.

Es waren nicht alle Orte als optional markiert. In folgenden Files musste ich die Anpassungen vornehmen:

• CsvExport.java => getDataFile()
• GpkgExport.java => getDataFile()
• Ili2gpkgImport.java => getDataFile()
• Ili2pgReplace.java =>getDataFile()
• Publisher.java => getSourcePath()
• ShpExport.java => getDataFile()
• Ili2gpkgAbstractTAsk.java => getDbFile()

Du musst einschätzen, wo es allenfalls möglich wäre eine existierende Datei vorauszusetzen und wo nicht. Ich gehe auch davon aus, dass es nicht in allen Fällen relevant ist ob sich der Inhalt verändert hat oder nicht.

• Ein Connector Objekt kann nun nicht mehr mittels ['db', 'dbuser', 'pw'] automatisch gemappt werden. Es musste ein alternativer Setter geschrieben werden, der eine Liste von Values annimmt und dann den Connector erstellt. Siehe z.b. GpkgExport.java. Das könnte man mittels Utils Funktion noch schöner lösen. Aktuell ist es etwas viel duplizierter Code.

Ja, wenn es jetzt in jedem DB-Task vorkommt. Können wir noch diskutieren.

Ich habe einen Task in unserem Project Board erstellt: #157

[Saela]

@edigonzales Konnte ich als OutputFile annotieren. Das passt nun auch besser zur Logik.

[Saela]

@edigonzales Auch hier passt OutputFile besser als Annotation.

[Saela]

@edigonzales Hier habe ich gesehen, dass vorausgesetzt wird, dass die InputFiles bestehen (zumindest ist der Test so aufgebaut). Deshalb habe ich hier die Annotation auch angepasst.

[Saela]

@edigonzales Hier muss es @input bleiben, da man eine FileCollection, ein File oder einen String (Ili ID) übergeben kann.

[Saela]

Hier wäre @OutputFile nicht logisch aus meiner Sicht. Auch @InputFile passt irgendwie nicht. In der TaskAction wird mit dem Pfad dann eine Datei erstellt/geholt. Daher habe ich @input gelassen.

[Saela]

@edigonzales

[Saela]

@edigonzales hier konnte ich ebenfalls OutputFile verwenden.

[Saela]

@edigonzales Auch hier macht OutputFile mehr Sinn.

[Saela]

@edigonzales Du kannst nochmals über den PR schauen. An den Stellen an welchen ich @input mit @OutputFile ersetzen konnte habe ich dir einen kurzen Kommentar gemacht. So findest du diese einfacher. :)

[edigonzales]

@Saela Bin kein Git-Experte. Squash and merge ist i.O.?

[Saela]

@Saela Bin kein Git-Experte. Squash and merge ist i.O.?

ja squash merge passt👍🏻