Auch dieses Jahr hat die W-JAX wieder in München stattgefunden. Am 12.11 habe ich einen Vortrag zu Maven gehalten. Der Titel: Maven von den Ketten befreit.
In großen Softwareentwicklungsprozessen ist Automatisierung ein wichtiges Element um reproduzierbare Ergebnisse zu erhalten. Besonders die Unabhängigkeit von der Entwicklungsumgebung ist für mich ein wichtiges Merkmal für professionelle Softwareentwicklung. Ein großes Riskio für den Erfolg eines Softwareprojektes ist, wenn ein Projekt nur aus der Entwicklungsumgebung heraus erzeugt werden kann. Da Systeme abstürzen, Festplatten kaputt gehen können braucht es hier die Reproduzierbarkeit. Unabhängig von Personen. Aus diesem Grund ist ein automatisierter Buildprozess unerlässlich.
Bei Namics ist Maven ein gesetztes Werkzeug. In dem Vortrag habe ich aus unserem Erfahrungsschatz berichtet.
Bei Maven wird der Entwickler mit drei Begriffen konfrontiert:
- Goal: Kleinste Ausführungseinheit von Maven (vergleichbar mit Task von ANT); Beispiel: mvn compile:compile
- Phase (Lebenszyklusphase): mehrere Goals; Beispiel: mvn package
- Lebenszyklus (Lifecycle): Geordnete Folge von Phase; Beispiel: clean (pre-clean, clean, post-clean)
Wer noch auf Maven 2.0.x hantiert sollte zumindest den Wechsel zu Maven 2.1.x in Betracht ziehen. Neben der zusätzlichen Phase pre-package ist hervorzuheben das die Abhängigkeiten nun in Threads (Standardeinstellung:5) heruntergeladen werden.
Anhand eines Beispiels habe ich einen möglichen Migrationspfad von ANT zu Maven aufgeführt. Folgende Schritte sind in der Präsentation aufgeführt:
- Schritt 1: Build Analyse
- Schritt 2: Verzeichnisstruktur anpassen
- Schritt 3: Dependency Management
- Schritt 4: Migration kleinstes Modul
- Schritt 5: Migration aller Moduln
- Schritt 6: Mavenize
- Schritt 7: CI
Der Umstieg von ANT zu Maven zieht eines an Änderungen nach. Dies liegt daran das Maven ein System mit dem Grundsatz Convention-over-Configuration ist. Wenn Sie den Konventionen folgen müssen Sie wenig anpassen. Sollte doch eine Anpassung erforderlich sein können eigene Plugins geschrieben werden. Auch der Lebenszyklus kann in der lifecycle.xml angepasst werden. Zusätzlich habe ich als Erweiterung zu Maven das Plugin Sonar gezeigt.
Damit besteht die Möglichkeit die QS-Daten eines Projektes in einer ansprechenden GUI zu visualisieren. Hier lohnt sich der Einsatz wirklich.
Den Abschluss bildete ein kurzer Blick auf das kommende Maven 3. Mit Maven 3 wird die pom.xml auch für die polyglotte Welt der JVM geöffnet. Es wird z.B. möglich das POM mit Groovy zu schreiben. Es bleibt spannend.
Bei Fragen zu Maven, Buildprozessen oder anderen Themen rund zum Softwareentwicklungsprozess sprechen Sie uns an.
Hallo Markus Staeuble,
Danke für den ausführlichen Vortrag zu maven. Allerdings bleibt für mich noch ein Punkt offen, für den ich bislang keine vernünftige Lösung gefunden habe.
Bei komplexen Produkten besteht der Build immer aus einer Mischung aus Artefakten, die Code liefern und einer produkt- bzw. kundenspezifischen Konfiguration.
Besonders deutlich wird das z.B. bei J2EE-Komponenten, die in mehreren Produkten eingesetzt werden. Hier unterscheiden sich die Komponenten oft nur in der Konfiguration, die aus XML-Deskriptoren bezogen werden.
Wie kann ich mit Maven diese Aspekte vernünftig behandeln? Der manuelle Weg wäre ja, das Archiv der Komponente auszupacken, den Deskriptor auf das Produkt anzupassen und danach wieder einzupacken und sie als produktspezifische Variante zu verwenden.