Softwareentwicklung im Team – Teil 3 – Dependency Management

Im letzte Artikel ging es um einen unabhängigen Buildprozess. Damit einhergehend stellt sich unweigerlich die Frage nach einem Dependency-Management.
Kleine Anmerkung vorweg für die die es nicht wissen: eine WAR-Datei ist ein Web Application Archive.

2. Problem / Beispiel
Dependency-Management
Unsere Applikation hat wahrscheinlich mehr JARs in den WARs als überhaupt benötigt werden. Darüber hinaus passiert es immer wieder, dass neue JARs hinzugefügt werden, die manuell in den Projekt-Properties nachgeflegt werden müssen. Außerdem treten die ersten Versionskonflikte auf (z.B. Classloader-Exception beim Mailversand). Diese werden sich mit einem automatisierten Dependency Management nicht vollständig lösen lassen, aber solche Probleme, dass sich eine Library in zwei verschiedenen Versionen im SELBEM Projekt befinden, auf jeden Fall.

Lösungsvorschlag
Unter der Prämisse, dass eins der oben vorgeschlagenen Tools verwendet wird, bietet sich entweder Ivy (http://ant.apache.org/ivy/) an oder der das in Maven schon integrierte Dependency Management.

Vorteile
– Es werden nur noch benötigte JARs ins WAR gepackt
– Abhängigkeiten von Libraries werden automatisch aufgelöst
– Es entfällt die Konfiguration seitens des Entwicklers, da das Dependency Management im Buildprozess integriert ist

Nachteile / Probleme
– Umstellung benötigt kurzfristig ein wenig Zeit / Einarbeitung
– Jeder Entwickler muss sich in das verwendete Tool einarbeiten und es auch nutzen!
– Abhängigkeiten zu eigenen Projekten benötigen ein eigenes Repository. Das Aufsetzen eines Solchen könnte anfangs etwas mehr Zeit in Anspruch nehmen, da meines Wissens nach, noch niemand (von uns) so etwas gemacht hat. Für Maven gibt es ein Tool namens Nexus (http://nexus.sonatype.org/) für diese Aufgabe.

Aufwand
Ich gehe davon aus, dass das Umstellen und das Aufsetzen der Infrastruktur für das erste Projekt ungefähr zwei Tage in Anspruch nehmen könnte. Pessimistisch geschätzt, könnte eine Umstellung aller Projekte eine Woche dauern.

Rückblickend gesehen…
Wie bereits im letzten Artikel erwähnt, haben wir uns damals für Maven entschieden und entsprechend auch dessen Dependency-Management verwendet. Als Maven Repository Manager wurde wie vorgeschlagen Nexus installiert.
Das Umstellen der Projekte erfolgte, wenn ich mich recht entsinne, tatsächlich innerhalb einer Woche, welche aber gut investiert war. Wobei ein Großteil der Zeit dafür drauf ging, Nexus aufzusetzen, sich einzuarbeiten (auch wenn Nexus recht simpel ist, so ist es eben nicht ganz selbsterklärend) und die Mitarbeiter entsprechend in die neuen Tools einzuweisen.
Für seltene, aber immer wiederkehrende Schritte, wie das Publishing/Aktualisieren eines eigenen Repository in Nexus, wurde ein Beitrag im Wiki veröffentlicht, zu welchem jeder Entwickler Zugang hatte. Zwar wurde das den Mitarbeitern in der Einweisung ebenfalls gezeigt, da diese Aufgabe aber eher sporadisch auftrat, waren die Arbeitsschritte bis dahin in der Regel wieder vergessen.
Bei den Vorteilen hatte ich angeführt, dass nur noch benötigte JARs verwendet werden. Dies ist so natürlich nicht korrekt. Wenn man Maven anweist, eine Bibliothek zu inkludieren ohne das diese überhaupt benötigt wird, landet diese eben doch noch im Projekt. Allerdings kommt man nicht mehr so schnell in Versuchung, 20 JARs ins Projekt zu kopieren, nur in der Hoffnung, dass sämtliche Abhängigkeiten damit aufgelöst seien, weil einem die genauen Abhängigkeiten nicht bekannt sind. (Struts 2 war zu diesem Zeitpunkt ein Framework, welches Unmengen an Abhängigkeiten benötigte, die aber von den verwendeten Plugins wieder abhingen. Und bevor man stundenlang versuchte, die Minimalkonfiguration herauszufinden, kopierte man dann doch eben auf die Schnelle ein paar Dateien mehr. Ob das bei Struts 2 immer noch der Fall sein sollte, weiß ich nicht).

Benötigte ein Entwickler eine neue Bibliothek, so trug er diese einfach in die pom.xml (die Konfigurationsdatei von Maven) ein und checkte diese mit seinen restlichen Änderungen ins SVN ein. Beim nächsten Update eines anderen Entwicklers, zog sich Maven automatisch die neuen Abhängigkeiten aus dem Repository und ein manuelles nachpflegen der Abhängigkeiten gehörte von da an, der Vergangenheit an.

Für uns war und ist Maven (auch nach knapp 1,5 Jahren) immer noch eine gute Wahl gewesen. Das liegt unter anderem sicherlich auch daran, dass wir uns an den Maven-Standard gehalten haben, was die Projektstruktur anbelangt. Das wird Kontrollfreaks, die ihre eigene Struktur verwenden wollen, sicherlich sauer austoßen.

Wie bei jeder (Tool-)Entscheidung sollte jedes Team für sich die Alternativen sorgfältig abwägen und zumindest ansatzweise auch mal ausprobieren. Das gilt nicht nur für das Buildtool (sondern ebenso für Frameworks, IDEs, Designfragen, Programmiersprachen, etc.)!

Das sich an solchen Themen die Geister scheiden können, zeigt ein recht aktueller Blog-Artikel und die Reaktionen, die er hervorgerufen hat:
Java Build Tools: Ant vs. Maven
“Maven – eine Ausgeburt der Hölle”
Maven sucks?

Und noch ein aktueller Link, der zwar nichts mit den obigen Artikeln zu tun hat, aber dennoch zeigt, dass dies ein ständig aktuelles Thema ist: http://www.symphonious.net/2010/01/11/comparing-build-systems/

Schön auch die verschiedenen Meinungen innerhalb der Kommentare. Aber bildet euch selbst ein Bild.

Zusammenfassung
Wir haben damals enorm davon profitiert, auf einen (De-Facto-)Standard zu setzen und nicht unser eigenes Süppchen zu kochen, indem wir selber anfangen Ant-Skripte zu schreiben (oder gar unser eigenes Build-Tool).
Ziel sollte es sein, dass ein neuer Entwickler im Team einfach nur das Projekt aus dem Versionskontrollsystem auschecken muss und ohne viel Kopfzerbrechen das Projekt bauen kann. Wie und mit welchen Mitteln, ist egal, auch wenn Standards dabei hilfreich sein können.

Ausblick
Im nächsten Beitrag geht’s (wieder mal in der Geschichte der Softwareentwicklung) um: Dokumentation!

2 Gedanken zu „Softwareentwicklung im Team – Teil 3 – Dependency Management“

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>