Apache Ant hat uns seit der Firmengründung gedient. Jedes Projekt hatte seine eigene build.xml, sorgfältig von Hand gepflegt, mit Dutzenden von Targets. Mit fünfzehn aktiven Projekten und sechs Entwicklern wurde es unwartbar. Ein neuer Mitarbeiter verbrachte seinen ganzen ersten Tag nur damit, den Build-Prozess zu verstehen.
Warum Maven und nicht Gradle?¶
Gradle existiert 2011, ist aber relativ jung und wird in der Enterprise-Java-Welt kaum eingesetzt. Maven 3 ist stabil, hat ein riesiges Plugin-Ökosystem und die meisten IDEs unterstützen es von Haus aus. Convention over Configuration ist genau das, was wir brauchen. Die Standardverzeichnisstruktur (src/main/java, src/test/java) bedeutet, dass jeder Entwickler sofort weiß, wo er Dinge findet.
Migrationsstrategie¶
Alle fünfzehn Projekte auf einmal zu migrieren wäre Wahnsinn gewesen. Wir entschieden uns für einen schrittweisen Ansatz: zuerst das firmeninterne Nexus-Repository, dann gemeinsame Bibliotheken, kleinere Projekte und schließlich die großen Multi-Module-Projekte. Die gesamte Migration dauerte drei Monate.
Nexus als Firmen-Repository¶
Nexus OSS ist die Grundlage des gesamten Ökosystems. Es fungiert als Proxy für Maven Central, hostet unsere internen Artefakte und ermöglicht Staging für den Release-Prozess. Die Konfiguration proxied Maven Central, das JBoss-Repository und das Oracle Maven Repository für JDBC-Treiber.
Die größten Probleme¶
Transitive Abhängigkeiten. Wenn man eine Abhängigkeit hinzufügt, lädt Maven automatisch alle deren Abhängigkeiten herunter. Ergebnis? Eine WAR-Datei mit 200 JARs, von denen einige in Konflikt stehen. Lösung: mvn dependency:tree und großzügiger Einsatz von Exclusions. Wir erstellten eine firmenweite Parent-POM mit einer dependencyManagement-Sektion.
Oracle JDBC-Treiber. ojdbc6.jar ist aufgrund von Lizenzeinschränkungen nicht in Maven Central. Wir mussten es manuell in Nexus hochladen.
Multi-Module-Projekte¶
Unsere größte Anwendung hatte in Ant eine einzige riesige build.xml mit 2000 Zeilen. In Maven teilten wir sie in Module auf: core, persistence, service, web, ear. Build des gesamten Projekts: mvn clean package. Sieben Minuten inklusive Tests. Mit Ant waren es fünfzehn Minuten.
Fazit¶
Die Migration von Ant zu Maven ist eine Investition, die sich innerhalb von Monaten amortisiert. Ein standardisierter Build-Prozess, automatisches Dependency Management und die Integration mit dem CI-Server haben unseren Entwicklungszyklus dramatisch beschleunigt.
Brauchen Sie Hilfe bei der Implementierung?
Unsere Experten helfen Ihnen bei Design, Implementierung und Betrieb. Von der Architektur bis zur Produktion.
Kontaktieren Sie uns