Wenn man im Unternehmen Maven als Software Configuration Management-Software einsetzt, um Software-Artefakt-Abhängigkeiten zu modellieren und auflösen zu lassen, sollte man umsichtig handeln. Natürlich sollte man grundsätzlich umsichtig handeln, aber wenn dieses Unternehmen auch noch wächst oder zunehmend Altsysteme durch neue ablöst, kann ein Abhängigkeits-Graph entstehen, der zwar analysiert werden kann, aber leichte Wartung unmöglich macht. Dieses „Wuchern“ kann man aber in den Griff bekommen.

Es kann leicht passieren, dass n Artefakte gegen m andere Artefakte gebaut und dabei die Versionen der Abhängigkeiten dezentral verwaltet werden. Wir sagen dazu gerne: „Das ist historisch gewachsen.“ Das ändert allerdings nichts an der Tatsache der schlechten Wartbarkeit bzw. dem Zeitaufwand, den man in die Wartung investieren muss. Natürlich gibt es Plugins, die bis zu einem gewissen Grad Abhilfe schaffen, aber das ist nur eine Linderung der Symptome.

Schauen wir uns einmal an, wie so ein „historisch gewachsener“ Abhängigkeits-Graph aussehen könnte:

Abhängigkeiten (alt)

Auf den ersten Blick wird klar, dass hier Struktur fehlt. Eine Möglichkeit der besseren Strukturierung ist die Einführung einer Parent-POM pro Schicht. So werden die Abhängigkeiten zentralisiert und man kann Plugins und Builds immer präziser spezifizieren. Die überarbeitete Variante sähe demnach so aus:

Abhängigkeiten (neu)

In Verbindung mit dem Maven Enforcer Plugin (angesiedelt auf unterster Ebene) kann dann auch sichergestellt werden, dass kein Build aus der Reihe tanzt und man kann sich auf unternehmensweite Konventionen im Betrieb und in Projekten verlassen.