Java-Build-Systeme
-
Hi!
Einer der Hauptgründe, warum es in Debian keine aktuelle Version von Mediathekview gibt, ist das sich zu oft ändernde Build-System: ant -> gradle -> maven. Gibt es vielleicht eine Geschichte, wie es zur Wahl und den Änderungen kam? Eine Reihenfolge wie ant -> maven -> gradle wäre wohl durch zeitliche Weiterentwicklung von Java-Build-Systemen zu erklären.
P.S. Ich habe in der develop-Branch 10 Kotlin-Dateien bemerkt. Wird der neue Code nun in Kotlin entwickelt? Im Rahmen des GSoC 2019 hat man angefangen in Debian Kotlin zu paketieren aber es ist noch nicht fertig.
-
@smotrelkin die wahl des build systems ist den beteiligten Entwicklern geschuldet. Wir haben uns auf maven geeignet da es einfacher ist und mehr Erfahrung vorliegt.
Einige Sachen wurden in Kotlin geschrieben da wir uns dafür interessieren. Es sollte aber egal sein ob unter debian ein kotlin compiler package vorliegt da das build file alles automatisch zieht. Zumindest unter Ubuntu und macOS habe ich nichts installiert und kann ohne Probleme bauen. Aber ich gebe zu ich halte mich von Debian fern…
Was mich jedoch wundert: Wieso hat die Wahl des Build-Systems Auswirkungen auf die Packages? OOTB sollte sowohl maven als auch gradle auch unter Debian funktionieren?
-
Ich habe mich vor kurzem auch noch mal mit Debain beschäftigt und der Umstand, jede Dependency als Debian Paket zu benötigen und das komplette building mit so debian skripten zu machen hat mich maximal abgeschreckt. Wir nutzen maven u.a. um damit unsere dependencies zu verwalten und damit die Anwendung zu bauen. Das funktioniert super. Ich sehe es ehrlich gesagt nicht ein nur für Debian extra alle Deps bei denen zu suchen und ggf. einzupflegen nur damit die glücklich sind. Wir haben ein fertiges Debian file das könnte man gern automatisiert publishen aber jetzt dafür extra sich deren Ökosystem zu 100% zu unterwerfen ist etwas krass.
Die meisten Nutzer haben noch dazu Windows und Mac da bringt uns das nichts.
Was ich stattdessen momentan mache ist, ein Flatpackage aufzubauen. Dann haben wir AppImage unf Flatpack. Wenn wir Lust haben kommt evtl. noch Snap. Dann wäre eig. alles abgedeckt. Da das Debian Image auch den Auto-Updater ab MV 13.6 mitbringt sollte das aber auch kein Problem sein ohne Repository.
-
Und von ant auf gradle auf maven war da sich bei der übernahme viele Entwickler mit dem Wunsch nach gradle meldeten aber dann, kaum war der umbau fertig, direkt wieder verschwunden waren. Wir haben dann gradle noch eine Weile gemacht und es war ein unübersichtliches chaos bei dem selbst einfache Dinge wie wein maven repository publish recht komplex wurde. Noch dazu neigen Gradle Files dazu schnell unübersichtlich zu werden. Daher dann der wechsel zu maven. Das kennen wir alle gut und das ist schön strukturiert.
-
@DerReisende77, @Nicklas2751 danke für die Erläuterungen!
Beim Paketieren fängt alles in debian/rules mit dem Build-System an. Und die bereits vorhandenen Pakete müssen alles enthalten, damit sie von dem jeweiligen Build-System auch gefunden werden.
Der weitere wichtigste problematische Grund sind die Abhängigkeiten. Aber nicht nur, sondern auch die Abhängigkeiten dieser Abhängigkeiten und, leider, so fort. Klar, dass Projekte sich nicht an die Debian-Einschränkungen halten sollen.
Der bekannte Vorteil von Debian ist der Fakt, dass während des Bauens nichts aus dem Internet heruntergeladen wird. Es kommen nur zuvor gesicherten Quelltext-Archive, die mit einer Prüfsumme versehen sind und bereits vorhandene Debian-Pakete. Viele Pakete können endlich auch reproduzierbar gebaut werden. Damit erlangt man die Überprüfbarkeit, dass das, was gebaut wurde, tatsächlich aus den verwendeten Quelltexten erfolgte. Um das zu erreichen, müssen aber alle Projekte zum Teil aufwändig paketiert werden. Je mehr Abhängigkeiten aktualisiert ein Projekt desto aufwändiger ist es auch bei kleinen eigenen Änderungen das Paket zu aktualisieren. So scheint es offenbar zu sein.
Bei C/C++ Programmen spezifiziert man in der Regel keine genaue Version, wie 1.2.3, sondern es kommt nur darauf an, dass es die Version 1+ ist oder 1.2+. Bei Java wird leider die ganz genaue Version verlangt (und so bei jeder Abhängigkeit?), was den Aufwand unverhältnismäßig in die Höhe treibt. Wie gesagt, kein Projekt muss sich wegen Debian einschränken. Aber gibt es nicht eine Möglichkeit bei maven die Abhängigkeiten weniger strikt zu verlangen oder zumindest in README minimale Anforderungen an alle direkt verwendeten Abhängigkeiten anzugeben?
$ grep -c 'version>[^$]' pom.xml 54Oh, bei etwa 50 wird es sogar für Entwickler vielleicht nicht so leicht.
@Nicklas2751, danke für die Geschichte über Gradle. Jetzt ist alles klar. Es war also eher Hype und als es ernst zur Sache kam, machte das doch keinen Spaß mehr. Des Weiteren entwickelt sich Gradle schnell weiter (wahrscheinlich ohne Mehrwert für kleine Projekte), so dass man auf die unnötige Wartung verzichten kann.
Ich persönlich bin eher Fan von build from source als Flatpack&Co. Aber für die wenigen anderen Linux-Nutzer wäre das sicherlich eine sehr gute Lösung. Danke, dass ihr daran denkt. Wäre schön, wenn alle Infos/Empfehlungen in z.B. README.Linux zusammengefasst werden könnten.
