Migrate build system to gradle #107
Comments
|
Sounds great to me, had it on my mind as well to us gradle and get rid of the checked in jars. So from me you get a go. 👍 |
|
Related: mediathekview/MLib#14 |
|
Weitere Diskussion, aktuell hier: https://hub.mediathekview.de/s/7a34baa6-3467-4bd0-b4bf-d985d12e07bc/?wallEntryId=95 |
|
Ich kann auf dem Hub nichts sehen. Wenn man einige Interfaces erstellt und herausnimmt, wäre auch ein API-Modul möglich, was ich wirklich toll finden würde -- aber eines nach dem anderen. Auf jeden fall sollten keine .project-Dateien mehr im Ordner sein, keine .jars, keine ant-Skripte etc., wie das etwa bei Hibiscus der Fall ist. BTW: Eclipse is also supported, IntelliJ as well. |
|
Auf dem Hub musst du dich vorher registrieren. |
|
Schon klar. Schade, dass Github dafür nicht reicht. Postet ihr hier das Ergebnis? |
|
Die Mehrheit hat sich für gradle entschieden. |
|
Nur zur Bestätigung: Ist Grandle somit jetzt offiziell? :) |
|
Jap |
kaklakariada
changed the title
Das sehe ich als großen Nachteil, denn die zentralen Repositories halten nicht immer alles auf ewig vor. Ich bin in meinem Job als Softwareentwickler schon ziemlich oft über nicht mehr verfügbare Libraries gestoßen. Hier sollte entweder ein eigener Repository-Proxy gepflegt werden, oder die Libraries weiterhin eingecheckt und aus den entsprechenden Verzeichnissen verwendet werden. Nur so hat Software wirklich die Chance lange zu überleben und immer noch kompilierbar zu sein und somit auch mal schnell ein Fix eingebaut werden, selbst wenn es sonst jahrelang nicht notwendig war, etwas zu ändern und einige, oder alle, Abhängigkeiten nicht mehr aufgelöst werden können. Bzgl. IDE-Support muss ich sagen, dass da eigentlich Maven im Java-Umfeld deutlich weiter verbreitet ist und auch Netbeans jetzt nicht gerade die verbreitetste IDE (http://www.baeldung.com/java-ides-2016). Wollte ich nur mal anmerken, soll keine Kritik sein. PS: Keine Scripte mehr, aber Gradle-Wrapper-Skripte? Das ist jetzt auch ein kleiner Widerspruch in sich ;) PPS: Nur weil Ant bei vielen heute nicht mehr State-of-the-Art ist, ist es doch ein zuverlässiges Werkzeug, wenn es ordentlich eingesetzt wurde. Unnötigerweise auf andere Systeme aufsetzen, wenn doch alles funktioniert, verursacht Arbeit, die hätte sinnvoller eingesetzt werden können. |
|
@lookshe Der Vorteil von maven und gradle ist u.a. dass keine lisb/dependencies mehr im git rumgammeln müssen. Allg. sind binarys im svn/git/etc. nicht sehr ratsam und sollten vermieden werden. Ant wie es aktuell verwendet wird läuft so nur unter linux (mac?). Weiterer Vorteil von gradle und maven also sie laufen auch unter Windows. Das dependencies aus dem zentralen maven Repo verschwunden sind habe ich bisher noch nicht erlebt und auch von Kollegen noch nie etwas gehört. Auch in der Arbeit wird stark auf maven gesetzt da die Vorteile beim bau komplexer Großprojekte stark überwiegen. Gegen Einrichtung eines eigenen Gradle Repo Proxys spricht aber nichts. Btw. sollte doch mal eine dependencie verschwinden kann man die ja aus der letzten MediathekView version ziehen da die dependencies ja mit ins zip kommen da MV sonst ja garnicht gestartet werden kann. ;) |
|
Die von NetBeans erzeugten ant scripts laufen auch auf dem Mac. Aber die Mac Binaries baue ich aus diversen Gründen noch Teil automatisiert von Hand. |
|
Dann herzlichen Glückwunsch, wenn es bisher nicht passierte. Aber auch nicht vergessen, dass es meistens erst bemerkt wird, wenn man ein leeres lokales Repository hat und es Libraries sind, bei denen sich die Maintainer entscheiden es bspw. umzubenennen, in eigene Repos zu packen oder einfach löschen. Dann geht Jahre später auf einmal das Gesuche los, wenn man nicht einen Repository-Proxy hat. Davon abgesehen würde mich mal eine wirklich triftige Begründung interessieren, warum Binaries in der Source-Verwaltung nicht ratsam sind. Gegenargument meinerseits: Egal wann, egal wo, ich checke das Projekt aus und kann es bauen. Keine externen Abhängigkeiten, die u.U. nicht aufgelöst werden können oder in den entsprechenden Versionen nicht mehr vorliegen und erstmal geschaut werden muss, welche denn nun genutzt werden muss, mit dem weiteren Nachteil, dass eine neue Version nicht mehr kompatibel sein kann, bzw. realistisch betrachtet erstmal ausgiebig getestet werden müsste, bevor sie verwendet werden sollte. |
|
https://softwareengineering.stackexchange.com/questions/110518/binaries-in-source-control Btw. Dependencies dürfen nicht gelöscht werden jedenfalls nicht von der maven central: |
|
Ich möchte auch nochmal sagen, dass das Argument von @lookshe kein wirkliches ist. Mir ist kein Fall bekannt, dass je eine Dependency aus Maven Central gelöscht wurde. Und dank Signaturen sind sie auch verifizierbar.
Ganz einfach: Es sind generierte Artefakte. In ein CVS gehören keine generierten Artefakte sondern nur "Bauanleitungen", wie man an diese kommt.
Stimmt auch nicht, da man mit TravisCI continuous Integration hat. Man merkt es also schon früher.
Symantic Versioning: Man kann jede beliebige Version einer Major-Version nutzen. Wenn eine 1.9.1 nicht verfügbar ist, geht auch eine 1.9.x und wahrscheinlich auch eine 1.8.x und in jedem Fall eine 1.10.x. - man muss ja nicht gleich auf eine 2.x.x-Version upgraden.
Ich schreibe gerne Unit-Tests bis zum Abwinken. Gerade Apache- und Google-Artefakte sind aber auch sehr gut getestet. Nicht nur auf richtiges, sondern auch auf gleichbleibendes Verhalten. Travis CI kann automatisch zu anderen Tools, wie etwa codecov (Unit-Testing) und codacy (richtige Nutzung der Libraries) hochladen. Siehe mein FFB-Projekt: https://github.com/bmhm/ffb.depot.client. Es werden automatisch Unit-Tests ausgeführt. Grade-Support gibt es auch bei IntelliJ und Eclipse ab Mars/Neon. |
|
Ich wollte eine triftige Begründung und keine Links, die immer nur das selbe wiederkäuen. Ich weiß sehr wohl über die Vorteile Bescheid, bin aber auch schon so oft auf die Schnauze geflogen, weil die Dependencies halt nicht noch Jahre später sauber vorhanden und gepflegt waren. Und auch wenn gesagt wird, Löschen sei nicht erlaubt oder geht nicht, ich habe anderes erlebt. Es mag sein, dass das nicht aus dem Maven-Central gelöscht wurde (wobei ich dort schon Umbenennungen erlebt hatte), aber es wurde auf eine Pom im Maven-Central verwiesen, die wiederum auf andere Quellen verwies, sodass nichts mehr lief. Solange man es einmalig lokal gezogen hatte, fiel es nicht auf, erst wenn man das lokale Repository leert oder einen Rechner komplett neu aufsetzt. Und leider merkt man das nicht direkt bei der Verwendung, weil man einfach nur die Dependency reinpackt, aber nicht schaut, auf was das alles verweist und was wiederum deren Dependencies sind. Auch merkt man gern später erst, dass man auf einmal unterschiedliche Versionen der gleichen Library im Projekt hat, aus unterschiedlichen Dependencies, die sich dann auch noch beißen. Als Stichwort sei hier einfach mal Dependency-Hell genannt. |
Ich denke, dass so ein lebendiges Projekt zwischendurch mal die Dependencies aktualisieren wird.
Aber nicht bei Maven Central. Da wir nur Maven Central nutzen, ist das irrelevant. Es kann aber sein, dass neue Artefaktversionen neue GroupIds bekommen. Aber da muss man ja eh die pom.xml anpassen.
Das hat hier keiner vor: eine pom.xml mit parent einer fremd-pom.xml (bzw. bei Grade: Tief geschachtelte Module). Rest s.o.
Gerade da brilliert Maven. Den Tag dependencyManagement hast Du wohl leider noch nicht genutzt. |
|
Triftige Begründung siehe mein gleichzeitiger Kommentar vor deinem. |
|
Ich schließe dass hier, da die Diskussion zu sehr von der umstellung auf gradle abweicht die bereits in der Umsetzung ist. Wenn tatsächlich noch bedarf ist. Bitte entweder neues Issue oder Forum oder Hub oder aber ich denke hier ist nicht der richtige Ort dafür. |
Es sind keine generierten Artefakte, sondern die zum Bauen der Software notwendigen Libraries.
In der Theorie. Praktisch gibt es gern auch mal Inkompatibilitäten im Verhalten selbst bei Minor-Versionen.
Schön, nur wird jcenter verwendet...
Noch nicht, aber man weiß nicht was kommt. Und darauf achtet nachher niemand mehr!
Gerade wenn es jahrelang ohne Probleme läuft und man diese nicht anpassen muss, fällt es erst spät auf. Nur weil es gerade etwas lebendiger ist, lässt das nicht auf die Zukunft schließen.
Oft genug und schon oft genug geflucht, weil nämlich mit Exclusions gearbeitet werden musste, damit nicht die falschen Dependencies durch irgendwelche anderweitigen Abhängigkeiten reinkommen. |
Ganz toll, ich habe nichts gegen Gradle, ich will nur verflucht nochmal die Software auch in einigen Jahren noch lauffähig haben und deswegen kann man sich nicht auf Drittanbieter und irgendwelche irgendwo gehosteten Libraries verlassen. Nur weil von den hier anwesenden, teilweise deutlich jüngeren Entwicklern, noch nie jemand über die genannten Probleme stolperte, heißt es nicht, dass diese nicht vorhanden sind. Ich will einfach nur, dass entweder ein eigener Repository-Proxy verwendet wird, damit die verwendeten Libraries sichergestellt sind, oder diese eingecheckt sind und von dort verwendet werden. Beides widerspricht Gradle in keiner Weise und ist umsetzbar! |
|
Ich werde ein Repository-Proxy aufsetzen. |
|
Die Software wird so oder so laufen da ja keine neuen versionen ausgeliefert werden wenn diese nicht bauen. Weder Travis tut das noch einer von uns. D.h. für den Anwender wirds weiter funktionieren und wenn bei uns eine tatsächlich fehlt gibts den proxy und zur not kann man das zip öffnen und die lib da raus kopieren und dann doch lokal einbinden solange das aber nicht der fall ist ist alles gut. ;) |
|
Verstehe das Schließen nicht ganz. Das läuft auf GitHub anders, als in einem Forum. Würde den Issue erst schließen, wenn Gradle auch eingebaut wurde. |
|
What do you mean @criztovyl ? |
|
Huh, vertippt, meinte #132. |
|
Ah ok. War als ich den Kommentar geschrieben habe aber noch gar nicht gemerged, passt aber dann jetzt ja :) |
|
Tja du warst einfach zu früh :D |
I am willing to support the project by migrating the project by migrating the build system of the three sub-projects from ant to gradle and would like to know if your are interested in this.
Gradle is a build system for Java and other languages.
Advantages of gradle
Proposed changes for the three sub-projects
.shscriptssrc/main/javadist/folder.shscripts.gitignorePlease let me know if these changes are interesting for you and if I should start working on this.
P.S.: Thank you very much for continuing the work on this great project!
The text was updated successfully, but these errors were encountered: