JAX 2007: Maven 2 – Umstellung eines Projekts von Ant zu Maven 2 (Oliver Stauss, eXXcellent solutions)

Historie – von make über Ant, Maven 1 zu Maven 2. Einfluss der Rails-Community. Komplett neue Implementierung von 1.

Paradigmenwechsel: Nicht Build-Skripte erstellen, sondern Projekte konfigurieren.

Nicht das wie des zu erzeugenden, sondern das was. Mehr managen als erzeugen. OO-Mechanismen zur Konfiguration (also Projekt).

mvn2 hilft bei einem Großteil des Entwicklungsprozesses. Unterstützung für

• Kompilation
• Releaserstellung
• Bibliotheksabhängigkeiten
• Dokumentation
• Unit- und Integrationstests
• nn
• nn

Weniger ein Tool wie Ant – vielmehr eine standardisierte Best-Practices-Enforcment-Box.

Konzepte

Project Object Model, beschrieben in pom.xml. Name + Version + Typ, Vererbung, Unterprojekte (Module), Abhängigkeiten und Repos, Lifecycle- Plugin Konfigurationen, Profile, Properties, sonstiges (Issue Tracker, Version Control etc).

Artifact:

Ergebnis (Produkt) eines mvn2-Projekts. Typen: jar, war, ear, sar; plugin, archetype, pom.

Werden in Rep abgelegt. Jedes mvn2-Projekt erzeugt lediglich ein Ergebnis (dadurch Modularisierung erzwungen).

Goal

Wie Ant-Target.

Plugin

Logische Gruppierung von Goals. In Reps verwaltet.

Syntax: plugin:goal

archetype:create – Skeleton für weitere Projekte.

cargo:start – Für Java EE interessant.

compiler:compile: Quellcode kompilieren.

Repositories

Zentrale Stelle, in der alle Artifacts abgelegt werden. Zwei Type: Lokal (file://[user-home].m2/repository), Remote (z.B. http://repo1.maven.org)

Dependency-Management

Alle abhängigen Artefakte über Repositories verwaltet, werden nicht physische in das Projekt kopiert. Kein "Jarmaggedon".

Build-Lifecycle

Definiert in Phasen: validate-generate-resource-compile-test_compile-test-package-integration_test-install-deploy. Phasen mit plugin-goals verbunden.

Reports

QA-Reports, generelle Projektinformationen.

Frage: Wie funktioniert das innerhalb Eclipse?

Antwort: Plugins, libraries in rep

Ãœbergang von Ant zu Maven 2

Refactoring des Ant-Projekts. Projektstrukturen vereinfachen! Bei mehreren Artifacts in Unterprojekte aufteilen.

Auflösen der Abhängigkeiten. Verwendete Bibliotheken identifzieren (mit Version!) – das ist normalerweise der aufwendigste Punkt.

Einspielen von 3rd-Party- und Inhouse-Bibliotheken in internes Repository.

POM definieren. Spezielle Ant-Targets in mvn2 umsetzen. Weitere features nutzen, um Qualität zu steigern.

Beispiel: antAuthProject

/src und /test/src-Folders. /lib, /etc; client, common und server-Packages.

=> mvn: drei Verzeichnisse /server, /common, /client und eine pom.xml auf root-Ebene und jeweils in den drei Verzeichnissen. Sourcen darunter in /src/main (Mvn2-Konzept) und /src/test. Alles andere in /resources.

Auflösen der Abhängigkeiten: Gut, wenn Versionsnummer in jar-Namen enthalten sind.

mvn install:install-file, um Libs in Rep zu bekommen (für internes Rep).

Mvn-plugin für spezielle Ant-targets. <parent>-Tag für Submodule. Submodule erben Konfig des Hauptprojekts (z.B. Unit-Tests, CodeCoverage).