# Best practices / Gradle und co



## Kr0e (3. Feb 2012)

Hallo,

ich muss zu aller erst gestehen, dass ich noch nie mit Buildsystemen gearbeitet habe, da meine Projekte bislang "klein" genug waren, bzw. nur von mir oder maximal noch 2 anderen Leuten abhingen.

Daher war das nie wirklich etwas, was ich gebraucht habe bzw. ich wusste auch nie wirklich, was das ist.

Nun geht es um ein etwas größeres Projekt mit mehreren Leuten und wir würden das schon ganz gern professionell und gut wartbar aufziehen.

Da entstanden in der Runde auch noch einige Fragen, wie z.B:

- Wie sollte man Code gliedern ? Macht es Sinn für "Teilprojekte des Hauptprojekts" extra Projekte (in Eclipse) anzulegen, auch ggf. für Dinge wie API/Implementierung ? Oder führt sowas schnell zu Problemen beim Erstellen des Hauptprojekts ? (Ich meine, wenn 10 Projekte auf ieine Art untereinander Abhängigkeiten aufweisen, dann is das bestimmt nicht so schön...)

- Eclipse hat ja anscheinend auch eine Art internes Buildsystem, sofern ich das richtig sehe. Immerhin kann man ja auch im kleinen Umfang Ding erledigen wie Clean/Build/Test usw. Wenn man nun ein anderen Buildsystem wie z.B. Gradle oder Maven benutzt, was muss dann geändert werden, bzw. sollte man dann nich auch einen anderen Builder benutzen, als den internen Eclipse Builder ? Sonst hat man ja quasi alles doppelt...


Wie ihr sicherlich merkt, hab ich mich mit diesen Themen noch wenig/keine Erfahrung.
Vlt. ein paar Tipps, wie ihr es regelt oder vlt. Literatur, wo die Best Practices beleuchtet werden, etc.

Als abschließende Frage: Maven oder Gradle ? Ich hatte mir mal Maven angeschaut und hab iwie nicht verstanden, wo der Vorteil ist, bis auf die Tatsache, dass halt Dependencies von Repos automatischen geladen werden können... Aber das liegt mit Sicherheit daran, dass ich wie gesagt damit wenig bisher gemacht habe.

Zu Gradle hab ich einen 2stündigen Vortrag vom Ersteller gesehen und empfand das eigentlich als echt umfangreich und flexibel. Leider gibt es anscheinend kein wirkliches Eclipse Plugin, was das ganze natürlich etwas unpraktisch zu handhaben macht...

Naja, schreibt einfach mal, was ihr so denkt 

Gruß,
Chris


----------



## Wildcard (4. Feb 2012)

> Wie sollte man Code gliedern ? Macht es Sinn für "Teilprojekte des Hauptprojekts" extra Projekte (in Eclipse) anzulegen, auch ggf. für Dinge wie API/Implementierung ?


Ja, das macht sinn.


> Eclipse hat ja anscheinend auch eine Art internes Buildsystem, sofern ich das richtig sehe. Immerhin kann man ja auch im kleinen Umfang Ding erledigen wie Clean/Build/Test usw. Wenn man nun ein anderen Buildsystem wie z.B. Gradle oder Maven benutzt, was muss dann geändert werden, bzw. sollte man dann nich auch einen anderen Builder benutzen, als den internen Eclipse Builder ? Sonst hat man ja quasi alles doppelt...


Eclipse hat nicht wirklich ein 'internes Buildsystem'. Eclipse kompiliert automatisch inkrementel. Normalerweise brauchst du Maven usw. nicht ständig im laufenden Betrieb, das macht Eclipse. Maven ist wichtig um die Abhängigkeiten automatisiert herunterzuladen und zu paketieren.



> Ich hatte mir mal Maven angeschaut und hab iwie nicht verstanden, wo der Vorteil ist, bis auf die Tatsache, dass halt Dependencies von Repos automatischen geladen werden können...


Der Vorteil von Maven sind die Konventionen. Wenn du dich an die Konventionen hälst, dann funktioniert fast alles automatisch und andere Entwickler müssen sich nicht einarbeiten weil alles dem gängigen Standard entspricht.



> Zu Gradle hab ich einen 2stündigen Vortrag vom Ersteller gesehen und empfand das eigentlich als echt umfangreich und flexibel.


Da kann man sich sicherlich drüber streiten, aber Flexibilität ist nicht unbedingt was ich von einem Build Werkzeug möchte. Wenn das Tool keinen klaren Weg vorgibt, entsteht schnell Wildwuchs und Chaos. Einige Kollegen und ich haben gerade gute 10 Mannmonate damit verbracht ein Ant Buildscipt Chaos zu entzerren und durch Maven zu ersetzen. Ohne die Flexibilität von Ant, wäre das nicht so schwierig gewesen.



> Naja, schreibt einfach mal, was ihr so denkt



Du solltest unbedingt ein CI System verwenden um kontinuierlich zu integrieren und testen.
Ich kann Jenkins wärmstens empfehlen.


----------



## Kr0e (4. Feb 2012)

Tausend Dank =)


----------



## tuxedo (6. Feb 2012)

Kann Wildcard nur zustimmen.

Ant ist "ganz okay", aber Maven ist "super". Natürlich gubts auch Ecken und Enden bei Maven wo's mal hässlich wird. Aber für sicherlich >90% der Fälle muss man keine Verrenkungen machen. 

Jenkins (oder Hudson, wie man mag) sind da wirklich eine große Hilfe wenn es um komfortable Build-Automation geht. 
Und wenn man möchte kann man sich zu Jenkins und Maven noch ein Maven-Repo-Server/Proxy (Sonytape Nexus z.B.) installieren.

- Alex


----------



## bygones (7. Feb 2012)

Wildcard hat gesagt.:


> Da kann man sich sicherlich drüber streiten, aber Flexibilität ist nicht unbedingt was ich von einem Build Werkzeug möchte. Wenn das Tool keinen klaren Weg vorgibt, entsteht schnell Wildwuchs und Chaos. Einige Kollegen und ich haben gerade gute 10 Mannmonate damit verbracht ein Ant Buildscipt Chaos zu entzerren und durch Maven zu ersetzen. Ohne die Flexibilität von Ant, wäre das nicht so schwierig gewesen.


ich weiss nicht wie sehr du dich mit Gradle auseinandergesetzt hast, aber die Aussage klingt falsch bzw in keiner Weise hat das mit Gradle etwas zu tun.

Gradle ist in seiner einfachsten Form nichts anderes als Maven in Groovy (simple gesagt) - es erlaubt einem mehr Flexibilitaet ala Ant.

Im Grunde kann man sagen - haelt man sich an die Konventionen von Maven/Gradle, so laeuft alles einfach und automatisch. Will man sich nicht an Konventionen halten, so erlaubt Gradle ein flexibleres Umgehen damit.


----------



## Wildcard (7. Feb 2012)

Ich bezog mich nie direkt auf Gradle, sondern auf den Wunsch nach Flexibilität. Und Flexibiltät ist bei Build Tools bestenfalls überbewertet und im schlechtesten Fall kontraproduktiv.
Alles was man konfigurieren kann, wird irgendwann, irgendwo auch immer missbraucht anstatt sich damit auseinander zu setzen, warum das eigene Projekt immer so viel spezieller ist als alle anderen


----------



## dermoritz (24. Feb 2012)

hier mal mein senf (vor einigen Monaten war an einem ähnlichen Punkt).
Tools:

Maven
Eclipse
Redmine (Ticketsystem und Projektmanagement - für mich nicht mehr wegzudenken - Tip kam aus diesem Forum)
Jenkins (inzwischen würde ich klar gegen Hudson tendieren - ich glaube fast die ganze alte Hudson-Community ist bei Jenkins?!)
Nexus, kostenlos-Variante ("Repository Management" - insbesondere für die Ablage eigener Bibliotheken/Releases wichtig, gibt auch Open-Source Alternativen)

Zum Aufbau/ Einteilung:
Prinzipiell gibt es bei größeren "Teilprojekten"/Bibliotheken 2 Alternativen der Auslagerung:
1. Maven-Modul: Würde ich nur nehmen wenn die enthaltenen Module sehr stark voneinander abhängen z.b. Die Versioniereung in soll in allen Modulen synchron sein, die Module teilen ein Großteil der Konfiguration (Mavencode). In meinem Projekt habe ich so das Hauptprojekt und die Integrationstests getrennt (sehr zu empfehlen)
2. Eigenes Maven Projekt: So habe ich meine Bibliotheken untergebracht z.B. eine die Dokumente (pdf, excel..) für das Hauptprojekt erzeugt. Die stärkere Trennung ist hier von Vorteil: Die Konfiguration ist eine ganze andere (es ist eine simple jar und keine webapp) die Versionierung auch: die Bibliothek wurde am Anfang mal erstellt und wurde seid Monaten nicht angefasst (Version ist gleich). Die Abhängigkeit zu dieser Bibliothek wird wie jede andere in das Hauptmodul eingetragen.

Das Eclipse sein eigenes Buildsystem hat ist insbesondere im Zusammenhang mit Maven ein Dorn im Auge. Bis Eclipse 3.6 benutzte man "m2eclipse" als Eclipse-Maven-Plugin. Das versucht so gut es geht die beiden auseinander zuhalten - funktioniert nicht immer (Project clean, mvn clean helfen aber meistens ;-)). Mit Eclipse 3.7 gibt es eine neue Version des Plugins "m2e" das macht alles wohl anders (ich benutze nicht 3.7) - auf den ersten Blick mit mehr Konfigurationsaufwand?!
Je nach Projekt lohnt es sich vielleicht tatsächlich mal in Richtung Netbeans zu schauen?! (für Google Web Toolkit aus meiner Sicht keine ALternative)


----------



## kama (24. Feb 2012)

Hallo,



Wildcard hat gesagt.:


> Der Vorteil von Maven sind die Konventionen. Wenn du dich an die Konventionen hälst, dann funktioniert fast alles automatisch und andere Entwickler müssen sich nicht einarbeiten weil alles dem gängigen Standard entspricht.


Das wird dann gerne als Nachteil von Maven verkauft ;-)...



Wildcard hat gesagt.:


> Da kann man sich sicherlich drüber streiten, aber Flexibilität ist nicht unbedingt was ich von einem Build Werkzeug möchte. Wenn das Tool keinen klaren Weg vorgibt, entsteht schnell Wildwuchs und Chaos. Einige Kollegen und ich haben gerade gute 10 Mannmonate damit verbracht ein Ant Buildscipt Chaos zu entzerren und durch Maven zu ersetzen. Ohne die Flexibilität von Ant, wäre das nicht so schwierig gewesen.


Genau so sehe ich das auch. Flexibilität ist meiner Meinung nach ein No-Go...

Gruß
Karl Heinz Marbaise


----------

