Gradle #32
Gradle #32
Conversation
Projekt kompiliert, die Tests laufen durch und eine Jar kann gebaut werden. Jedoch fehlen noch ein paar Dinge, bevor ANT vollständig ersetzt ist. Deshalb existieren weiterhin die Dateien in den Ordnern `lib`, `lib.src`, `build`.
|
Danke für das Patch. Ich hätte dazu noch ein paar Anmerkungen:
|
|
Sehr gerne. Ich werde schauen, ob ich die angefragten Dinge umsetzen kann, und melde mich dann wieder hier. |
|
Bzgl. SWT (unterster Bulletpoint): Bei den Zip-Dateien gibt es für die Sektion "SWT Binary and Source". Hier findet man etwa 3,5MB große ZIP-Dateien. Jede enthält als Inhalt die
Bei den Maven-Repositories sind jeweils zwei Jar-Dateien (swt.jar 2MB und swt-src.jar 1,9MB). Zusätzlich existiert eine Abhängigkeit zu
Ich habe die Inhalte der beiden --- swt_maven_content.txt 2021-06-09 18:58:13.000000000 +0200
+++ swt_zip_content.txt 2021-06-09 18:57:58.000000000 +0200
@@ -1,16 +1,5 @@
-.api_description
META-INF/
-META-INF/ECLIPSE_.RSA
-META-INF/ECLIPSE_.SF
META-INF/MANIFEST.MF
-about.html
-about_files/
-about_files/IJG_README
-about_files/lgpl-v21.txt
-about_files/mpl-v11.txt
-about_files/mpl-v20.txt
-about_files/webkit-bsd.txt
-fragment.properties
libswt-atk-gtk-4942r22.so
@@ -365,6 +354,7 @@
org/eclipse/swt/internal/Converter.class
+org/eclipse/swt/internal/DPIUtil$1.class
org/eclipse/swt/internal/DPIUtil$AutoScaleImageDataProvider.class
@@ -377,6 +367,47 @@
org/eclipse/swt/internal/SWTMessages.properties
+org/eclipse/swt/internal/SWTMessages_ar.properties
+org/eclipse/swt/internal/SWTMessages_bg.properties
+org/eclipse/swt/internal/SWTMessages_cs.properties
+org/eclipse/swt/internal/SWTMessages_da.properties
+org/eclipse/swt/internal/SWTMessages_de.properties
+org/eclipse/swt/internal/SWTMessages_el.properties
+org/eclipse/swt/internal/SWTMessages_en_CA.properties
+org/eclipse/swt/internal/SWTMessages_es.properties
+org/eclipse/swt/internal/SWTMessages_et.properties
+org/eclipse/swt/internal/SWTMessages_eu.properties
+org/eclipse/swt/internal/SWTMessages_fa.properties
+org/eclipse/swt/internal/SWTMessages_fi.properties
+org/eclipse/swt/internal/SWTMessages_fr.properties
+org/eclipse/swt/internal/SWTMessages_hi.properties
+org/eclipse/swt/internal/SWTMessages_hu.properties
+org/eclipse/swt/internal/SWTMessages_id.properties
+org/eclipse/swt/internal/SWTMessages_it.properties
+org/eclipse/swt/internal/SWTMessages_iw.properties
+org/eclipse/swt/internal/SWTMessages_ja.properties
+org/eclipse/swt/internal/SWTMessages_ko.properties
+org/eclipse/swt/internal/SWTMessages_ku.properties
+org/eclipse/swt/internal/SWTMessages_lt.properties
+org/eclipse/swt/internal/SWTMessages_lv.properties
+org/eclipse/swt/internal/SWTMessages_ml.properties
+org/eclipse/swt/internal/SWTMessages_mn.properties
+org/eclipse/swt/internal/SWTMessages_nl.properties
+org/eclipse/swt/internal/SWTMessages_no.properties
+org/eclipse/swt/internal/SWTMessages_pl.properties
+org/eclipse/swt/internal/SWTMessages_pt.properties
+org/eclipse/swt/internal/SWTMessages_pt_BR.properties
+org/eclipse/swt/internal/SWTMessages_ro.properties
+org/eclipse/swt/internal/SWTMessages_ru.properties
+org/eclipse/swt/internal/SWTMessages_sk.properties
+org/eclipse/swt/internal/SWTMessages_sl.properties
+org/eclipse/swt/internal/SWTMessages_sr.properties
+org/eclipse/swt/internal/SWTMessages_sv.properties
+org/eclipse/swt/internal/SWTMessages_th.properties
+org/eclipse/swt/internal/SWTMessages_tr.properties
+org/eclipse/swt/internal/SWTMessages_uk.properties
+org/eclipse/swt/internal/SWTMessages_zh.properties
+org/eclipse/swt/internal/SWTMessages_zh_TW.properties
org/eclipse/swt/internal/SessionManagerDBus$IListener.class
@@ -580,6 +611,7 @@
org/eclipse/swt/widgets/Menu.class
+org/eclipse/swt/widgets/MenuItem$1.class
org/eclipse/swt/widgets/MenuItem$MaskKeysym.classWie man sieht, fehlen in der Maven-JAR die Folglich würde ich in der Gradle-Konfiguration weiter auf die Quelle "Maven-Central" setzen und die Entwickler nicht zum manuellen Download der ZIP-Datei plus aller Abhängigkeiten verpflichten. |
|
Zum ersten und zweiten Bulletpoint
Maven nutzt Konfigurationsdateien (endet auf Sollte eine neuere Version einer Abhängigkeit benötigt werden (d.h. Modul A benötigt nun Modul B mit einer anderen Versionsnummer), so wird diese neue JAR (von Modul B) bei einem Update ebenfalls automatisch nachgeladen und zentral abgelegt. Maven nutzt für die zentrale Ablage den Ordner |
|
Ich werde noch etwas Zeit investieren, um ausprobieren, wie die in ANT deklarierten Abläufe auch von Gradle aufgerufen werden können (signieren von Dateien etc.) und melde mich hier wieder. |
Danke für die Recherche. OK, dann kann man die SWT-Versionen aus dem Repo ja zumindest erstmal testweise im Nightly-Build verwenden. Wobei ich schon ziemlich blöd finde, dass man bei den Versionsnummern überhaupt keine Vergleichsmöglichkeit hat. Man hätte ja statt 3.116 auch 4.19.116 verwenden können. |
Mir gings hier gar nicht um einen Vergleich Maven/Gradle. Ich meinte nur, dass das folgende Schnipsel aus der build/download.gradle mit in die build.gradle übernommen werden könnte, damit man durch Aufruf von "gradle download" sich einmal alle Deps herunterladen und im Ordner "lib/download" innerhalb des Jameica-Projektes speichern lassen kann. Derzeit mit Ant pflege ich die Abhängigkeiten in "lib" ja noch per Hand. Solange das Build-Script für die Signierung und die verschiedenen OS-Paketierungen noch nötig ist, kann ich mit "gradle download" schnell und einfach die aktuellen Abhängigkeiten lokal speichern und danach manuell prüfen, welche Libs in "lib" aktualisiert werden müssten: |
|
Für SWT gibt es ein Gradle-Plugin, das SWT für eine bestimmte Version und die betriebssystemspezifischen Pakete herunterladen kann. |
|
Danke für den Hinweis. Aber das ist dann die Version für die Plattform, auf der Build-Script gerade läuft. Das Script sollte ja aber in der Lage sein, Releases für jede Plattform zu erzeugen. |
|
Die Dokumentation ist leider nicht die beste, aber an sich ist das möglich. Für die Entwicklung an sich ist es ganz angenehm, für die Releases könnte man das |
|
Vielen Dank für den Tipp, @tstenner! Ich habe mir den Quelltext von dem Plugin angeschaut und es verweist stets hardcoded auf currentOs. Es gibt leider keine Methode, die man nutzen könnte, um per Angabe des Betriebssystems und der Architektur die entsprechenden JARs herunterzuladen. Somit könnte man es nur nutzen, um die Versionnummer in die Buildnummer übersetzen zu lassen... Deswegen habe ich mich nochmal daran versucht, den
Das hätte den Vorteil, dass man in der Nach etwas Recherche habe ich in Groovy hinbekommen, dass eine Liste mit allen Permutationen erzeugt wird. Was ich in der Dokumentation von Gradle jedoch noch nicht verstehe, ist wie man programmatisch die Abhängigkeiten ergänzt. In https://stackoverflow.com/a/55160963 steht ein triviales |
|
Man könnte auch mit Github Actions die Pakete nativ auf dem jeweiligen OS direkt bauen. |
|
Aber bei Github Actions läuft der Buildprozess doch auf einem Server von Github. Dann lassen sich die Builds nicht mehr signieren. |
|
@willuhn Doch, du kannst die Keys für das Signieren hinterlegen: https://docs.github.com/en/actions/reference/encrypted-secrets |
|
Also ich möchte eigentlich keine Private-Keys auf einen Server hochladen. Da muss ich ja drauf vertrauen, dass alles mit rechten Dingen zugeht. Kontrollieren kann ich es nicht mehr. meine persönlichen Anforderungen an die Vertrauenswürdigkeit einer solchen Signatur erfüllt das jedenfalls nicht. Ich erstelle die Releases bisher ausschliesslich lokal auf meinem Rechner. |
|
ok, kann ich verstehen. Wem auch immer man vertraut/misstraut 🤷 |
|
Ich baue die Releases auf dem Rechner und direkt auf dem Code (also nicht auf einem dedizierten Clone), auf dem ich auch entwickle. Da gibt es quasi kein clone oder pull. Sondern meine eigenen Commits. Und wenn mal jemand einen PR einreicht, dann schaue ich mir die Diffs sehr genau an, bevor sie lokal in meinem Code landen. Es geht um eine Banking-Anwendung. Das finde ich schon ein sehr sensibles Thema, da man echten finanziellen Schaden auslösen kann. Daher versuche ich jedes Risiko zu vermeiden, soweit ich Kontrolle darüber habe. |
An sich schon, die Pakete sind aber bis auf die plattformabhängigen SWT-jars identisch. So wirklich not tut das also nicht.
Nur interessehalber: kann man die fertig gebauten Pakete herunterladen und dann lokal signieren? Hätte immer noch das Problem, dass man dem Buildserver vertrauen muss, aber der Schlüssel landet nicht irgendwo. Für nicht-signierte Builds (und um die Unit tests für PRs durchlaufen zu lassen) fände ich Github Actions trotzdem praktisch.
Ja. Das Repository ist zwar bei Github hinterlegt, aber kleinste Änderungen würden zwangsläufig dazu führen, dass die Checksummen (d.h. die ID von jedem Commit) abweicht. Zusätzlich hat man die Github-Server auch schon in der |
Das ist korrekt. Man muss nicht auf der Zielplattform bauen.
Zumindest für die Signatur der ZIP-Dateien würde das gehen. Wobei da schon meine Paranoia ansetzt, weil ich dann nicht mehr garantieren kann, dass ich wirklich genau dieses Build signiere oder die Datei zwischen Build und Download manipuliert wurde. Wenn ich es komplett lokal per Ant baue, wird unmittelbar nach der Erstellung der ZIP-Datei direkt die Signatur erzeugt. Unabhängig davon sind auch direkt die Klassen von Jameica und Hibiscus signiert. Das muss unmittelbar nach der Erstellung der JARs und noch vor dem Erstellen der ZIP-Dateien passieren, da die Signaturen der Klassen im "manifest"-Ordner innerhalb des JAR landen. Hierfür wird ein Java-Keystore benötigt, der nur lokal auf meinem Rechner existiert.
Das stimmt. Damit könnte man auch die Nightly-Builds erzeugen. Derzeit werden die auf meinem Server täglich als Cronjob erzeugt. Da das automatisiert passiert, haben die gezwungenermaßen auch keine Signaturen. |
|
Ich habe nun mit ruderphilipp/jmc@5823ed7 einen Gradle-Task geschrieben, der die SWT-Jar-Dateien für alle Plattformen herunterlädt. Als Ersatz für den alten Über zentrale Module (siehe ruderphilipp/jmc@d53adf0) im Sinne von DRY sind Ordnerstruktur oder Encoding einmalig definiert und als Einzeiler nutzbar. Dadurch fällt die jeweilige Konfiguration in der
Die Themen "Signieren" sowie "Ausliefern" mit Gradle sind noch offen. Es gibt Plugins für Packen, Signieren und auch welche, um z.B. direkt danach die JAR zu Maven-Central hochzuladen. Ebenso das von @tstenner aufgeworfene Thema "Github Actions" ist noch offen/ unter Diskussion, da ich noch nicht herausgefunden habe, wie soetwas mit einem Gradle-Multiproject-Build über mehrere Repositories realisierbar wäre. Bei Vorschlägen diesbezüglich bin ich aber gern bereit, zu unterstützen. Dafür wäre dann ein neuer Pull-Request (wahrscheinlich gegen https://github.com/ruderphilipp/jmc, da zentral zu konfigurieren) notwendig. Jedoch möchte ich diese drei Themen HIER gern aus dem Scope ausklammern und somit das Thema "Gradle" abschließen wollen, da ich mich wieder der Arbeit an Verbesserungs- und Erweiterungsvorschlägen am Code zuwenden möchte. |
|
Kannst du das Löschen der download.gradle bitte noch aus dem Commit rausnehmen? Ich möchte das gern noch verwenden, solange der Build-Prozess noch nicht komplett auf Gradle umgestellt ist. |
This reverts commit 1f2dd10.
|
Danke |
|
Hallo @willuhn, Zusätzlich kannst Du auch das Kommando |
|
Wie wollen wir jetzt weiter verfahren? Zum Bauen ist ja jetzt das übergeordnete Meta-Projekt notwendig. |
Ich werde im Projekt JMC die Repositories auf die Originale umlenken. Aktuell zeigen sie noch auf meine Forks, da ja überall die Gradle-Umstellung einige Anpassungen notwendig gemacht hat. Anschließend muss nur einmal das Projekt als Basis ausgecheckt werden. Innerhalb der Unterordner kann man ganz regulär die Branches wechseln, Änderungen pushen usw. |
Also wenn der Aufruf genau das selbe macht wie mein Code in download.gradle, dann kann meine download.gradle doch gelöscht werden ;) |
Wie in #27 beschrieben, ist die Einstiegshürde recht hoch und kann durch die Nutzung von Gradle vereinfacht werden.
Ich habe mich von der guten Vorarbeit von @MichaelSp inspirieren lassen, jedoch basierend auf den Kommentaren in #27 einen anderen Ansatz verwendet: Alles bleibt in Github und ich habe ausschließlich die für Gradle notwendigen Dateien ergänzt. Die ANT-Skripte bleiben vorerst erhalten, wo notwendig (Gradle nutzt einen Unterordner in "build", sodass ein
./gradlew cleannicht jene Dateien löscht).Weitere angesprochene Aktivitäten wie etwa eine Umstellung des Encodings werden hier nicht angegangen. Stattdessen habe ich die Konfigurationsdateien für IntelliJ IDEA im Toplevel-Projekt (siehe unten) ergänzt, sodass auch diese IDE korrekt eingerichtet wird.
Eine Codeentwicklung ist damit möglich. Nach Umstellung aller Teilprojekte auf Gradle werden beim Aufruf von
gradle clean build test jarim Toplevel-Projekt alle Dateien kompiliert, die Tests ausgeführt und eine JAR-Datei erstellt.Für das Toplevel-Projekt habe ich ein neues Repository erstellt, das die Mechanismen von git-submodule nutzt, um die anderen Repositories dynamisch einzubinden. Auch ich erhebe keine Besitzansprüche darauf und kann gern die "Ownership" transferieren.