SubscribeZum vierten Mal ein ALT.NET Bier im schönen Köln, diesmal zum Thema Buildmanagement (mit Maven). Stefan, Sergey, Lars und ich hatten dazu Christian Raschka eingeladen. Nach einem kleinen “warm-up” gings ab 19h mit einer Einführung in Maven los. Anschließend diskutierten wir den aktuellen Stand des NPanday-Projektes (früher: NMaven).
Maven ist ein java-basiertes System zum Buildmanagement. Maven ist dabei nur eine sehr kleine Laufzeitumgebung, die erst durch die große Zahl verschiedenster Plugins zum Leben erwacht und arbeitet. Interessant für ALT.NET sind dabei vor allem die Konzeote und Ideen – auch wenn in gemischten Umgebungen ein java-basiertes Buildsystem durchaus pragmatisch erscheint.
Während Ant, NAnt und MSBuild als imperativ aufgefasst werden können, ist Maven rein deklarativ: Man beschreibt was man möchte (Abhängigkeiten, Compiler, Testrunner, Analysen, Reports, …) und Maven kümmert sich um den Rest. Grundsätzlich gilt hier “Convention-over-Configuration”. Es gibt für alles sinnvolle Standardwerte. Zusätzlich sind bestimmte “best practices” als feste Regeln in Maven verbaut. So ist zum Beispiel die Struktur eines Moduls/Projektes immer gleich. Dies hat den Vorteil, dass man darüber nicht mehr nachdenken muss, alle Projekte gleich aussehen und der Standard bereits erprobt ist. Die verschiedenen Bestandteile eines “build” (Phasen!) sind in Maven fest verbaut und entstehen nicht – wie bei Ant – durch das aneinanderreihen von “targets”. Der Vorteil: Eine Phase heißt überall auf der Welt gleich und nicht einmal install, einmal compile und einmal build – hier greifen auch die angesprochenen best practices. Zusätzlich erledigt eine Phase immer die selbe Aufgabe, egal in welchen Projekt (Phasen können trotzdem erweitert werden).
Eine Assembly (oder in Java: JAR) wird in Maven auch Artefakt genannt. Ein Artefakt kann Abhängigkeiten zu anderen, eigenen Modulen haben oder aber auch externe Abhängigkeiten.
Alle Plugins werden genauso wie Abhängigkeiten zu anderen Modulen aufgefasst: Alles ist eine Abhängigkeit des Buildprozesses. Fehlt ein Plugin oder eine Abhängigkeit, so wird dieses von zentralen Servern (sog. “Repositories”) heruntergeladen. Dort können wiederum weitere (transitive) Abhängigkeiten hinterlegt sein; diese werden dann auch geladen. Alle Artefakte werden in einem lokalen Repository abgelegt, dieses funktioniert also als Cache. Für Unternehmen lohnt sich der Einsatz eines Proxy-Repositories im Unternehmensnetzwerk. Dieser Proxy hat seinen eigenen Cache und versucht Anfragen zunächst daraus zu bedienen. Fehlen hier Artefakte, werden diese über konfigurierbare zentrale Repositories heruntergeladen.
Maven vergibt für erstellte Artefakte automatisch Buildnummern, die sich niemals doppeln können. Grundsätzlich ist jeder Build zunächst als sog. “Snapshot” mit dem jeweiligen System-Benutzernamen markiert. Erst ein spezielles Plugin erzeugt auf Wunsche in komplettes Release. Zur Erzeugung eines solchen gehört dann auch der Upload auf ein angegebenes Repository. Auf öffentlichen zentralen Repositories sind idR keine Snapshots zu finden, dies garantiert die Stabilität der veröffentlichen Versionen. Wer dennoch gegen den “trunk/HEAD” bauen möchte, kann meist Snapshot-Versionen von den Servern der jeweiligen Projekte bekommen. Da Abhängigkeiten mit Versionsnummern definiert werden sollten (oder mit Versionsbereichen), erreicht Maven somit die so wichtige Reproduzierbarkeit von Builds.
Alle beschriebenen Abhängigkeiten eines Artefakts werdem mit dem Project Object Model (POM) beschrieben. Dazu können auch Angaben über das verwendete SCM (mit Pfad zum Checkout) oder ein Ziel-Repository für Releases gehören. Fehlt der Quellcode kann Maven diesen automatisch aus dem gegebenen SCM herunterladen. Wird ein Release erzeugt, wird zunächst kontrolliert, ob im SCM noch Änderungen vorhanden sind. Falls es solche gibt, werden diese zunächst auch “ausgecheckt”. Anschließend wird der komplette Build durchgeführt und der Stand im SCM getagged. Das fertige Release wird dann ins lokale Repository und in das angegebene Ziel-Repository installiert.
Für .NET gibt es schon länger ein Reihe von Maven-Plugins, um .NET Compiler, Testrunner, Analysen, etc. zu unterstützen. Nach 2 Jahren im Apache Incubator konnte das Projekt aber nicht genügend Geschwindigkeit und Halt in der Community erzeugen. Deshalb ist der aktuelle (funktionierende) Stand nun unter neuem Namen nach Codeplex gewandert. Die Plugin-Sammlung heißt nun NPanday. Damit ist Maven sicherlich näher an .NET gerückt, fraglich ist aber ob der Ansatz einer Java-Runtime beibehalten werden kann. Derzeit scheinen die Pläne vorzusehen, sich noch stärker mit MSBuild im Rücken zu verbinden und langfristig die Java-Abhängigkeit zu verlieren. Auch veröffentlichen derzeit keine der großen Open Source Projekte in der .NET Welt ihre Artefakte auf zentralen Repositories. Für mehr Sichtbarkeit von Maven und die Aufnahme von mehr Geschwindigkeit müssten sicherlich Projekte wie NHibernate, Castle Windsor, Spring.NET, NUnit, xUnit, … sich beteiligen und ein Deployment auf einem zentralen Server pflegen. Dazu müsste man sicherlich “unten” anfangen und die Basis (Unittesting-Frameworks, Castle Dynamic Proxy) zuerst deployen, damit alle darauf aufsetzenden Projekte ihre Abhängigkeiten korrekt definieren können.
