#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]

• 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]

• 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: https://github.com/sogis/gretl/issues/157

[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👍🏻