Maven vs. Gradle or why I moved back from Gradle to Maven

Ich war schon immer ein Fan von Maven. Ich kenne noch die schrecklichen Ant-Zeiten. Dann kam vor einiger Zeit (oder Jahren) Gradle auf den Tisch. Schneller, Hipper, Einfacher?!

Ich fühlte mich bei den ersten Tutorials wieder bei Ant und konnte dem ganzen nichts abgewinnen. Dennoch überlege ich regelmäßig (bin halt auch noch ein Technik-Nerd), ob ich nicht kleine Services damit bauen sollte.

Ich bin heute auf folgenden Artikel gestoßen: https://blog.philipphauer.de/moving-back-from-gradle-to-maven/

Wollte ich hier nur einmal Teilen und verbleibe zunächst weiter mit Maven. :slight_smile:

1 „Gefällt mir“

Kann ich nachvollziehen. Gradle mit Kotlin könnte einige der Probleme lösen, das probieren wir gerade in der Firma aus. Bei einem privaten Projekt habe ich dieselbe Umstellung versucht, und habe es dann sein lassen, weil ich nicht alles, was ich gebraucht habe, entsprechend “übersetzt” bekam, und nicht zu viel Zeit reinstecken wollte. Ich hoffe sehr, dass sich das noch verbessert.

Ich habe über die Jahre auch sehr viel Erfahrung mit Maven gesammelt. Wie in dem Artikel beschrieben, ist Maven nicht mein größter Schmerzpunkt.

Du kannst ja mal von der Nutzung Gradle<->Kotlin berichten, wenn ihr da etwas zustande bekommt.

Kann ich gerne machen, aber der Hauptvorteil wird einfach das statische Typing sein.

Danke fuer den Link @anon2594669 :slight_smile:

Ich natuerlich ein Maven Fan wie man an meinem alten Posts leicht erkennen kann, meine zugegeben geringe Erfahrungen mit Gradle waren aber nicht das was ich mir erwartet hatte nachdem ich von vielen Ecken hoerte wieviel besser es sein sollte…

Was mich an Maven nie stoerte: XML
Wenn man viel mit Builds arbeitet (und das habe ich), war XML weder an Ant noch an Maven je ein echtes Problem. Dadurch dass es „starke“ bzw. „strikte“ Konventionen gab, konnte man den Build deklarativ beschrieben.

Das Problem an Ant war: keine Konventionen aber stattdessen den Build skripten!
Dass dann natuerlich XML sich als nicht gerade passen erweist ist sollte nicht ueberraschen, aber das eigentliche Problem, keine Konventionen aber skripten, aendert sich kein bisschen.
Diese einzigartigen Schneeflocken and Builds die ich in Ant gesehen habe und der damit verbundene Aufwand an Pflege dieser Projekte war nie ausgeglichen mit den vermeintlichen Vorteilen die es bringen sollte.
Genau da machte Gradle denselben Fehler: „Man kann alles moegliche in einem Build damit machen, total flexibel!“

Groovy, oder jede andere Programmiersprache, koennen schlicht nicht die Luecke von echten Standards/Konventionen schliessen, sondern machen diese nur groesser, weil es ploetzlich viel mehr Moeglichkeiten gibt vermeintlich kreativ zu werden.

Die Einschraenkungen die der lokale Workflow des Entwicklers und die IDE erfordern - zB. IntelliJs langsame import/index Zeiten, ein Entwickler will nicht staendig bei „null“ anfangen muessen, d.h. kein clean sondern am besten inkrementell bauen, was dann aber sehr schnell zu veralteten Caches fuehrt und dann ein „bei mir gehts aber“ zur Folge hat - waehrend CI schlicht pruefen muss dass das Gegenteil geht: wenn man staendig bei null anfaengt, soll es immer noch funzen oder eben nicht, aber auf jedenfall reproduzierbar.

Builds sind komplex und werden es immer sein, fuer mich haben weder Ant noch Gradle ( und vor allem nicht SBT) die Probleme die Maven hat (und die hat es) geloest, ich sehe die als Rueckschritt in vielerlei Hinsicht.

Das geht mir tatsächlich auch so. Bestimmt kann man sagen, dass ich mich einfach daran gewöhnt habe. Aber ich empfinde dies als angenehm strukturiert.