Maven Definitive Guide De

Thomas Locher (Sonatype, Inc.), Tim O'Brien (Sonatype, Inc.), John Casey (Sonatype, Inc.),
Brian Fox (Sonatype, Inc.), Bruce Snyder (Sonatype, Inc.), Jason Van Zyl (Sonatype, Inc.),
Eric Redmond ()

Copyright © 2006-2008

Copyright ....................................................................................................... xii
1. Creative Commons BY-ND-NC ......................................................... xii
Vorwort zur deutschen Ausgabe: 0.5 ............................................................ xiv
Vorwort .......................................................................................................... xv
1. Anleitung zu diesem Buch .................................................................. xv
2. Ihr Feedback ....................................................................................... xvi
3. Typographische Konventionen ......................................................... xvii
4. Konventionen in Bezug auf Maven .................................................. xvii
5. Danksagung ......................................................................................xviii
1. Einführung von Apache Maven ................................................................... 1
1.1. Maven ... Was ist das? ........................................................................ 1
1.2. Konvention über Konfiguration ......................................................... 2
1.3. Die gemeinsame Schnittstelle ............................................................ 3
1.4. Universelle Wiederverwendung durch Maven-Plugins ..................... 5
1.5. Konzeptionelles Modell eines "Projekts" .......................................... 6
1.6. Ist Maven eine Alternative zu XYZ? ................................................. 8
1.7. Ein Vergleich von Maven und Ant .................................................... 9
1.8. Zusammenfassung ............................................................................ 14
2. Installieren und Ausführen von Maven ...................................................... 15
2.1. Überprüfen der Java-Installation ...................................................... 15
2.2. Herunterladen von Maven ................................................................ 16
2.3. Installation von Maven ..................................................................... 16
2.3.1. Maven Installation unter Mac OSX ....................................... 17
2.3.2. Maven Installation unter Microsoft Windows ....................... 18
2.3.3. Maven Installation unter Linux .............................................. 19
2.3.4. Maven Installation unter FreeBSD oder OpenBSD ............... 19
2.4. Testen einer Maven Installation ....................................................... 19
2.5. Spezielle Installationshinweise ........................................................ 20
2.5.1. Benutzerdefinierte Konfiguration und-Repository ................ 21
2.5.2. Aktualisieren einer Maven-Installation .................................. 22
2.5.3. Upgrade einer Maven-Installation von Maven 1.x auf Maven
2.x ..................................................................................................... 23
2.6. Maven De-Installieren ...................................................................... 24

ii

Maven: The Definitive Guide

2.7. Hilfe bekommen beim Arbeiten mit Maven .................................... 24
2.8. Das Maven Hilfe Plugin ................................................................... 26
2.8.1. Beschreibung eines Maven Plugin ......................................... 27
2.9. Die Apache Software Lizenz ........................................................... 29
I. Maven by Example ..................................................................................... 31
3. Ein einfaches Maven Projekt .............................................................. 33
3.1. Einleitung .................................................................................. 33
3.1.1. Das Herunterladen der Beispiele dieses Kapitels ............ 33
3.2. Erstellen eines einfachen Projekts ............................................. 34
3.3. Der Aufbau eines einfachen Projekts ........................................ 36
3.4. Einfaches Projekt Objekt Modell (POM) .................................. 37
3.5. Kern Konzepte .......................................................................... 39
3.5.1. Maven Plugins und Ziele ................................................. 39
3.5.2. Maven Lifecycle .............................................................. 42
3.5.3. Maven Koordinaten ......................................................... 46
3.5.4. Maven Repositories ......................................................... 49
3.5.5. Maven Abhängigkeits-Management (Dependency
Management) ............................................................................. 52
3.5.6. Site-Generierung und Reporting ..................................... 55
3.6. Zusammenfassung ..................................................................... 56
4. Anpassen eines Maven Projektes ........................................................ 57
4.1. Einleitung .................................................................................. 57
4.1.1. Herunterladen der Beispiele dieses Kapitels ................... 57
4.2. Eine kurze Einführung in das "Simple Weather" Projekt ......... 57
4.2.1. Yahoo! Wetter Dienst RSS ............................................. 58
4.3. Erstellen des "Simple Weather" Projektes ................................ 59
4.4. Anpassen der Projektinformationen .......................................... 60
4.5. Einfügen neuer Abhängigkeiten ................................................ 62
4.6. Quellcode von "Simple Weather" ............................................. 64
4.7. Resourcen Hinzufügen .............................................................. 71
4.8. Ausführen des "Simple Weather" Programms .......................... 72
4.8.1. Das Exec Maven Plugin .................................................. 74
4.8.2. Erkundung der Projekt Abhängigkeiten .......................... 74
4.9. Erstellen von Unit-Tests ............................................................ 77

iii


4.10. Hinzufügen von Gebietsbezogenen Unit Tests ....................... 80
4.11. Hinzufügen einer Unit-Test Ressource ................................... 81
4.12. Ausführen von Unit-Tests ....................................................... 83
4.12.1. Ignorieren fehlgeschlagener Unit Tests ......................... 84
4.12.2. Überspringen von Unit-Tests ........................................ 86
4.13. Builden einer paketierten, Befehlszeilen orientierten
Anwendung ...................................................................................... 87
4.13.1. Anbinden des Assembly Goals zur Packetierungs Phase 89
5. Eine einfache Web-Anwendung ......................................................... 91
5.1. Einleitung .................................................................................. 91
5.1.1. Herunterladen der Beispiele dieses Kapitels ................... 91
5.2. Eine kurze Einführung in die "Simple Web" Anwendung ........ 91
5.3. Erstellen des "Simple Web" Projekts ........................................ 92
5.4. Konfigurieren des Jetty-Plugins ................................................ 93
5.5. Das Hinzufügen eines einfachen Servlets ................................. 96
5.6. Das Hinzufügen von J2EE-Abhängigkeiten ............................. 98
5.7. Zusammenfassung ................................................................... 100
6. Ein multi-modulares Projekt ............................................................. 101
6.1. Einleitung ................................................................................ 101
6.1.1. Herunterladen der Beispiele dieses Kapitels ................. 101
6.2. Das "Simple Parent" Projekt (parent=Elternteil) .................... 102
6.3. Das "Simple Weather" Modul ................................................. 103
6.4. Das "Simple-Web" Anwendungs-Modul ................................ 106
6.5. Erstellung des Multi-Projekt-Moduls ...................................... 109
6.6. Starten der Web-Anwendung .................................................. 110
7. Multi-module Enterprise Project ....................................................... 112
7.1. Einleitung ................................................................................ 112
7.1.1. Herunterladen der Beispiele dieses Kapitels ................. 112
7.1.2. Multi-Modul Enterprise Projekt .................................... 113
7.1.3. Technologie des Beispiels ............................................. 116
7.2. Das "Simple Parent" Projekt - Top Level ............................... 117
7.3. Das Simple Model" Modul - Das Objektmodell ..................... 119
7.4. Das "Simple Weather" Modul - Die Dienste .......................... 125
7.5. Das "Simple Persist" Modul - Die Datenabstraktion .............. 129

iv


7.6. Das "Simple Web" Modul - Das Web-Interface ..................... 139
7.7. Aufrufen der Web-Anwendung ............................................... 153
7.8. Das "Simple Command" Modul - Das Kommandozeilen Modul
......................................................................................................... 154
7.9. Aufrufen der Kommandozeilen-Anwendung .......................... 162
7.10. Fazit ....................................................................................... 164
7.10.1. Programmierung gegen Interface-Projekte ................. 166
8. Optimirung und Überarbeitung der POMs ........................................ 168
8.1. Einführung ............................................................................... 168
8.2. POM Bereinigung ................................................................... 169
8.3. Optimirung der Abhängigkeiten ............................................. 170
8.4. Optimirung der Plugins ........................................................... 176
8.5. Optimierung unter Zuhilfenahmen des Maven Dependency Plugin
......................................................................................................... 178
8.6. Abschliessende POMs ............................................................. 182
8.7. Fazit ......................................................................................... 190
II. Maven Reference ..................................................................................... 192
9. The Project Object Model ................................................................. 193
9.1. Introduction ............................................................................. 193
9.2. The POM ................................................................................. 193
9.2.1. The Super POM ............................................................. 196
9.2.2. The Simplest POM ........................................................ 200
9.2.3. The Effective POM ....................................................... 201
9.2.4. Real POMs .................................................................... 201
9.3. POM Syntax ............................................................................ 202
9.3.1. Project Versions ............................................................ 202
9.3.2. Property References ...................................................... 205
9.4. Project Dependencies .............................................................. 207
9.4.1. Dependency Scope ........................................................ 208
9.4.2. Optional Dependencies ................................................. 210
9.4.3. Dependency Version Ranges ........................................ 211
9.4.4. Transitive Dependencies ............................................... 213
9.4.5. Conflict Resolution ....................................................... 215
9.4.6. Dependency Management ............................................. 217

v


9.5. Project Relationships ............................................................... 219
9.5.1. More on Coordinates ..................................................... 220
9.5.2. Multi-module Projects ................................................... 221
9.5.3. Project Inheritance ......................................................... 223
9.6. POM Best Practices ................................................................. 227
9.6.1. Grouping Dependencies ................................................ 227
9.6.2. Multi-module vs. Inheritance ........................................ 229
10. Der Build Lebenszyklus .................................................................. 237
10.1. Einführung ............................................................................. 237
10.1.1. Lebenszyklus: clean .................................................... 237
10.1.2. Standard Lebenszyklus: default .................................. 241
10.1.3. Lebenszyklus: site ....................................................... 243
10.2. Package-spezifische Lebenszyklen ....................................... 244
10.2.1. jar ................................................................................. 245
10.2.2. pom .............................................................................. 246
10.2.3. plugin ........................................................................... 246
10.2.4. ejb ................................................................................ 247
10.2.5. war ............................................................................... 248
10.2.6. ear ................................................................................ 248
10.2.7. Andere Packetierungs Typen ...................................... 249
10.3. Gebräuchliche Lebenszyklus Goals ...................................... 251
10.3.1. Ressourcen Verarbeiten ............................................... 251
10.3.2. compile ........................................................................ 255
10.3.3. Verarbeiten von Test Ressourcen ................................ 257
10.3.4. Kompilieren der Test Klassen (testCompile) .............. 258
10.3.5. test ............................................................................... 258
10.3.6. install ........................................................................... 260
10.3.7. deploy .......................................................................... 260
11. Build Profiles .................................................................................. 262
11.1. What Are They For? .............................................................. 262
11.1.1. What is Build Portability ............................................. 262
11.1.2. Selecting an Appropriate Level of Portability ............. 264
11.2. Portability through Maven Profiles ....................................... 265
11.2.1. Overriding a Project Object Model ............................. 268

vi


11.3. Profile Activation .................................................................. 269
11.3.1. Activation Configuration ............................................. 271
11.3.2. Activation by the Absence of a Property .................... 272
11.4. Listing Active Profiles .......................................................... 273
11.5. Tips and Tricks ...................................................................... 274
11.5.1. Common Environments ............................................... 274
11.5.2. Protecting Secrets ........................................................ 276
11.5.3. Platform Classifiers ..................................................... 278
11.6. Summary ............................................................................... 280
12. Maven Assemblies .......................................................................... 282
12.1. Introduction ........................................................................... 282
12.2. Assembly Basics ................................................................... 283
12.2.1. Predefined Assembly Descriptors ............................... 284
12.2.2. Building an Assembly ................................................. 285
12.2.3. Assemblies as Dependencies ....................................... 288
12.2.4. Assembling Assemblies via Assembly Dependencies 289
12.3. Overview of the Assembly Descriptor .................................. 293
12.4. The Assembly Descriptor ...................................................... 296
12.4.1. Property References in Assembly Descriptors ............ 296
12.4.2. Required Assembly Information ................................. 296
12.5. Controlling the Contents of an Assembly ............................. 298
12.5.1. Files Section .............................................................. 298
12.5.2. FileSets Section ......................................................... 299
12.5.3. Default Exclusion Patterns for fileSets .................... 302
12.5.4. dependencySets Section ............................................. 303
12.5.5. moduleSets Sections ................................................... 317
12.5.6. Repositories Section .................................................... 325
12.5.7. Managing the Assembly’s Root Directory .................. 326
12.5.8. componentDescriptors and
containerDescriptorHandlers ............................................. 327
12.6. Best Practices ........................................................................ 328
12.6.1. Standard, Reusable Assembly Descriptors .................. 328
12.6.2. Distribution (Aggregating) Assemblies ...................... 332
12.7. Summary ............................................................................... 337

vii


13. Properties and Ressource Filterung ................................................. 338
13.1. Einleitung .............................................................................. 338
13.2. Maven Properties .................................................................. 338
13.2.1. Maven Projekt Einstellungen ...................................... 339
13.2.2. Properties der Maven Einstellungen (settings.xml) .... 342
13.2.3. Properties der Umgebungsvariablen ........................... 342
13.2.4. Java System Properties ................................................ 343
13.2.5. Benuzerdefinierte Properties ....................................... 345
13.3. Ressource Filterung ............................................................... 346
14. Maven in Eclipse: m2eclipse .......................................................... 351
14.1. Einführung ............................................................................. 351
14.2. m2eclipse ............................................................................... 351
14.3. Installation des m2eclipse Plugins ........................................ 352
14.3.1. Installieren der Voraussetzungen ................................ 353
14.3.2. Installation von m2eclipse ........................................... 355
14.4. Aufschalten der Maven Konsole ........................................... 356
14.5. Erstellen eines Maven Projekts ............................................. 357
14.5.1. Auschecken eines Maven Projektes von einem SCM
Repository ............................................................................... 358
14.5.2. Erstellen eines Maven Projekts auf der Basis eines Maven
Archetyps ................................................................................ 360
14.5.3. Erstellen eines Maven Moduls .................................... 364
14.6. Erstellen einer Maven POM Datei ........................................ 367
14.7. Importieren von Maven Projekten ........................................ 371
14.7.1. Importiren eines Maven Projektes ............................... 373
14.7.2. Materialisieren eines Maven Projektes ....................... 375
14.8. Starten von Maven Builds ..................................................... 379
14.9. Mit Maven Projekten arbeiten ............................................... 382
14.9.1. Zufügen und Updaten von Abhängigkeiten und Plugins 384
14.9.2. Erstellen eines Maven Modules .................................. 387
14.9.3. Herunterladen der Quelldatei(en) ................................ 387
14.9.4. Öffnen von Projektseiten ............................................. 387
14.9.5. Auflösen von Abhängigkeiten ..................................... 388
14.10. Arbeiten mit den Maven Repositorien ................................ 388

viii


14.10.1. Suchen von Maven Artefakten sowie Java Klassen .. 389
14.10.2. Indizierung von Maven Repositorien ........................ 394
14.11. Der neue graphische POM Editor ....................................... 398
14.12. Projektabhängigkeiten mit m2eclipse analysieren .............. 404
14.13. Maven Einstellungen ........................................................... 409
14.14. Zusammenfassung ............................................................... 417
15. Site Generation ................................................................................ 419
15.1. Introduction ........................................................................... 419
15.2. Building a Project Site with Maven ...................................... 420
15.3. Customizing the Site Descriptor ........................................... 422
15.3.1. Customizing the Header Graphics ............................... 423
15.3.2. Customizing the Navigation Menu ............................. 424
15.4. Site Directory Structure ......................................................... 426
15.5. Writing Project Documentation ............................................ 427
15.5.1. APT Example .............................................................. 427
15.5.2. FML Example ............................................................. 428
15.6. Deploying Your Project Website .......................................... 429
15.6.1. Configuring Server Authentication ............................. 430
15.6.2. Configuring File and Directory Modes ....................... 431
15.7. Customizing Site Appearance ............................................... 432
15.7.1. Customizing the Site CSS ........................................... 432
15.7.2. Create a Custom Site Template ................................... 433
15.7.3. Reusable Website Skins .............................................. 438
15.7.4. Creating a Custom Theme CSS ................................... 440
15.7.5. Customizing Site Templates in a Skin ........................ 441
15.8. Tips and Tricks ...................................................................... 443
15.8.1. Inject XHTML into HEAD ......................................... 443
15.8.2. Add Links under Your Site Logo ................................ 443
15.8.3. Add Breadcrumbs to Your Site ................................... 444
15.8.4. Add the Project Version .............................................. 445
15.8.5. Modify the Publication Date Format and Location ..... 446
15.8.6. Using Doxia Macros .................................................... 447
16. Repository Management with Nexus .............................................. 449
17. Writing Plugins ............................................................................... 451

ix


17.1. Introduction ........................................................................... 451
17.2. Programming Maven ............................................................. 451
17.2.1. What is Inversion of Control? ..................................... 452
17.2.2. Introduction to Plexus ................................................. 453
17.2.3. Why Plexus? ................................................................ 454
17.2.4. What is a Plugin? ......................................................... 455
17.3. Plugin Descriptor .................................................................. 456
17.3.1. Top-level Plugin Descriptor Elements ........................ 458
17.3.2. Mojo Configuration ..................................................... 459
17.3.3. Plugin Dependencies ................................................... 463
17.4. Writing a Custom Plugin ....................................................... 463
17.4.1. Creating a Plugin Project ............................................. 463
17.4.2. A Simple Java Mojo .................................................... 464
17.4.3. Configuring a Plugin Prefix ........................................ 466
17.4.4. Logging from a Plugin ................................................ 470
17.4.5. Mojo Class Annotations .............................................. 471
17.4.6. When a Mojo Fails ...................................................... 473
17.5. Mojo Parameters ................................................................... 474
17.5.1. Supplying Values for Mojo Parameters ...................... 474
17.5.2. Multi-valued Mojo Parameters .................................... 477
17.5.3. Depending on Plexus Components ............................. 479
17.5.4. Mojo Parameter Annotations ...................................... 479
17.6. Plugins and the Maven Lifecycle .......................................... 481
17.6.1. Executing a Parallel Lifecycle ..................................... 481
17.6.2. Creating a Custom Lifecycle ....................................... 482
17.6.3. Overriding the Default Lifecycle ................................ 484
18. Writing Plugins in Alternative Languages ...................................... 487
18.1. Writing Plugins in Ant .......................................................... 487
18.2. Creating an Ant Plugin .......................................................... 487
18.3. Writing Plugins in JRuby ...................................................... 490
18.3.1. Creating a JRuby Plugin .............................................. 491
18.3.2. Ruby Mojo Implementations ....................................... 493
18.3.3. Logging from a Ruby Mojo ........................................ 496
18.3.4. Raising a MojoError .................................................... 497

x


18.3.5. Referencing Plexus Components from JRuby ............ 497
18.4. Writing Plugins in Groovy .................................................... 498
18.4.1. Creating a Groovy Plugin ............................................ 499
19. Using Maven Archetypes ................................................................ 501
19.1. Introduction to Maven Archetypes ........................................ 501
19.2. Using Archetypes .................................................................. 502
19.2.1. Using an Archetype from the Command Line ............ 502
19.2.2. Using the Interactive generate Goal ............................ 503
19.2.3. Using an Archetype from m2eclipse ........................... 506
19.3. Available Archetypes ............................................................ 506
19.3.1. Common Maven Archetypes ....................................... 506
19.3.2. Notable Third-Party Archetypes ................................. 508
19.4. Publishing Archetypes .......................................................... 511
A. Appendix: Detailinformationen zur settings.xml-Datei .......................... 514
A.1. Übersicht ....................................................................................... 514
A.2. Die Details der settings.xml Datei ................................................ 515
A.2.1. Einfache Wertangaben ........................................................ 515
A.2.2. Servers ................................................................................. 516
A.2.3. Spiegelrepositorien .............................................................. 517
A.2.4. Proxies ................................................................................. 518
A.2.5. Profiles ................................................................................ 520
A.2.6. Activation ............................................................................ 520
A.2.7. Properties ............................................................................. 522
A.2.8. Repositories ......................................................................... 523
A.2.9. Plugin Repositories ............................................................. 525
A.2.10. Aktive Profile .................................................................... 526
B. Appendix: Alternativen zu den Sun Spezifikationen .............................. 528

xi

Copyright
Copyright 2008 Sonatype, Inc.
Online version published by Sonatype, Inc., 654 High Street, Suite 220, Palo Alto,
CA, 94301.
Print version published by O'Reilly Media, Inc., 1005 Gravenstein Highway North,
Sebastopol, CA 95472.
Nutshell Handbook, the Nutshell Handbook logo, and the O'Reilly logo are
registered trademarks of O'Reilly Media, Inc. The Developer's Notebook series
designations, the look of a laboratory notebook, and related trade dress are
trademarks of O'Reilly Media, Inc.
Java(TM) and all Java-based trademarks and logos are trademarks or registered
trademarks of Sun Microsystems, Inc., in the United States and other countries.
Many of the designations used by manufacturers and sellers to distinguish their
products are claimed as trademarks. Where those designations appear in this book,
and Sonatype, Inc. was aware of a trademark claim, the designations have been
printed in caps or initial caps.
While every precaution has been taken in the preparation of this book, the
publisher and authors assume no responsibility for errors or omissions, or for
damages resulting from the use of the information contained herein.

1. Creative Commons BY-ND-NC
This work is licensed under a Creative Commons Attribution-Noncommercial-No
Derivative Works 3.0 United States license. For more information about this
license, see http://creativecommons.org/licenses/by-nc-nd/3.0/us/. You are free to
share, copy, distribute, display, and perform the work under the following
conditions:

• You must attribute the work to Sonatype, Inc. with a link to
http://www.sonatype.com.

xii

Copyright

• You may not use this work for commercial purposes.

• You may not alter, transform, or build upon this work.
If you redistribute this work on a web page, you must include the following link
with the URL in the about attribute listed on a single line (remove the backslashes
and join all URL parameters):
<div xmlns:cc="http://creativecommons.org/ns#"
about="http://creativecommons.org/license/results-one?q_1=2&q_1=1
&field_commercial=n&field_derivatives=n&field_jurisdiction=us
&field_format=StillImage&field_worktitle=Maven%3A+Guide
&field_attribute_to_name=Sonatype%2C+Inc.
&field_attribute_to_url=http%3A%2F%2Fwww.sonatype.com
&field_sourceurl=http%3A%2F%2Fwww.sonatype.com%2Fbook
&lang=en_US&language=en_US&n_questions=3">
<a rel="cc:attributionURL" property="cc:attributionName"
href="http://www.sonatype.com">Sonatype, Inc.</a> /
<a rel="license"
href="http://creativecommons.org/licenses/by-nc-nd/3.0/us/">
CC BY-NC-ND 3.0</a>
</div>

When downloaded or distributed in a jurisdiction other than the United States of
America, this work shall be covered by the appropriate ported version of Creative
Commons Attribution-Noncommercial-No Derivative Works 3.0 license for the
specific jurisdiction. If the Creative Commons Attribution-Noncommercial-No
Derivative Works version 3.0 license is not available for a specific jurisdiction, this
work shall be covered under the Creative Commons
Attribution-Noncommercial-No Derivate Works version 2.5 license for the
jurisdiction in which the work was downloaded or distributed. A comprehensive
list of jurisdictions for which a Creative Commons license is available can be
found on the Creative Commons International web site at
http://creativecommons.org/international.
If no ported version of the Creative Commons license exists for a particular
jurisdiction, this work shall be covered by the generic, unported Creative
Commons Attribution-Noncommercial-No Derivative Works version 3.0 license
available from http://creativecommons.org/licenses/by-nc-nd/3.0/.

xiii

Vorwort zur deutschen Ausgabe: 0.5
Vor Ihnen liegt die deutsche Übersetzung der "Definitiv Guide to Apache Maven".
Ein Werk das, wie das englische Original, zum Ziel hat Brücken zu schlagen.
Brücken nicht nur zwischen Technikern und Techniken, sondern auch Brücken
zwischen unseren verschiedenen Kulturen.
In meiner täglichen Erfahrung gibt es eine grosse Zahl Arbeitsgruppen und Teams
welche mehr als eine, oft sogar so viele Nationalitäten wie Mitglieder umfassen.
Das Kommunikationsmedium ist meist der kleinste gemeinsame Nenner:
(Sowie-)Englisch. Wie oft habe ich nach tage- und nächtelangem Suchen
feststellen müssen, dass der Fehler eigentlich ganz offensichtlich war, wenn
Man(n) nur die (englische) Anleitung verstanden hätte!
Maven ist ein mächtiges Tool, häufiger missverstanden und nur rudimentär
eingesetzt - insbesondere weil die Zusammenhänge unklar, die Dokumentation in
Englisch schwierig und lückenhaft ist. Da ich vom Wert dieses Werkzeugs
überzeugt bin habe ich alles gegeben dieses Werkzeug auch dem deutschen
Sprachraum "native" zugänglich zu machen.
Ich erhoffe mir hiervon auch, Entwickler zu ermutigen sich in der grossen
bestehenden Maven Community einzubringen, Themen aufzugreifen und weiter zu
führen. Diesen Entwicklern möchte ich Sicherheit bieten indem ich Ihnen eine
Referenz zur Seite stelle, die sie verstehen.
Mit Blick auf unsere multinationalen Gruppen habe ich versucht das Werk so nahe
am englischen Original zu belassen als möglich. Sie werden also auf
Abschnittebene vergleichen können. Sollten Sie unsicher sein was Ihr Kollege
tatsächlich meint, so zücken Sie Ihr deutsches Exemplar, sehen nach welchen
Abschnitt im englischen Original Ihr Kollege referenziert - et voilà - lesen Sie in
Ihrer Muttersprache was gemeint ist.
Thomas Locher
Zürich, im Januar 2008
PS: Habe ich Ihnen bereits empfohlen die englische Originalausgabe zu kaufen?

xiv

Vorwort
Maven is ein Build Werkzeug, ein Projekt Management Werkzeug ein abstrakter
Container um Build Aufträge abzuarbeiten. Es stellt ein Werkzeug dar, welches
unumgänglich ist für alle Projekte welche über die einfachsten Anforderungen
hinauswachsen und sich plötzlich in der Lage finden konsistent eine grosse Zahl
voneinander abhängiger Bibliotheken zu Builden, welche sich auf dutzende oder
gar hunderte Komponenten (auch) von Drittparteien abstützen. Es ist ein
Werkzeug, das dazu beigetragen hat einen Grossteil des Verwaltungsaufwandes für
Komponenten aus dem Alltag von Millionen von Fachspezialisten zu eliminieren.
Es hat vielen Organisationen geholfen sich weiterzuentwickeln, hinweg über die
Phase des täglichen Kampf mit dem Build Management, hin zu einer neuen Phase
in welcher der Aufwand einen Build zu erhalten und zu pflegen nicht mehr eine
Grenzgrösse des Software Designs darstellt.
Dieses Buch ist ein erster Versuch eines umfassenden Werkes bezüglich Maven.
Es baut auf die gesammelten Erfahrungen und der Arbeit aller Autoren
vorgängiger Titel bezüglich Maven auf und Sie sollten dieses Werk nicht als
fertiges Werkstück ansehen sondern vielmehr als der erster Wurf einer langen
Reihe von Updates welche dieser Ausgabe folgen werden. Auch wenn es Maven
bereits einige Jahre gibt, so empfinden die Autoren dieses Werkes dennoch, dass
Maven erst gerade begonnen hat die kühnen Versprechen einzulösen welche auf
den Weg gegeben wurden. Die Autoren -wie auch die Firma- welche hinter diesem
Buch stehen, Sonatype glauben fest daran, dass dieses Werk dazu beitragen wird,
eine neue Welle der Innovation und Entwicklung in Umfeld von Maven und
dessen Ökosystem loszutreten.

1. Anleitung zu diesem Buch
Nehmen Sie dieses Buch in die Hand und lesen Sie einige Seiten des Textes. Am
Ende der Seite werden Sie, sollten Sie die HTML Ausgabe lesen, entweder den
Link zur nächsten Seite folgen wollen, oder im Fall der gedruckten Ausgabe
werden Sie die Ecke heben und weiterblättern. Sollten Sie vor einem Computer

xv

Vorwort

sitzen, so können Sie sicherlich das eine oder andere Beispiel durchspielen um dem
Text zu folgen. Was Sie nicht tun sollten, auch nicht in Wut, ist das Buch in die
Richtung eines Mitmenschen zu werfen - es ist einfach zu schwer!
Dieses Buch gliedert sich in drei Abschnitte: eine Einführung, einen Beispielteil
und eine Referenz. Die Einführung besteht aus zwei Kapiteln: Einführung und
Installation. Der Beispielteil führt Maven ein, indem einige echte
Anwendungsbeispiele eingeführt werden und Ihnen anhand der Struktur der
Beispiele weitere Motivation und Erklärung gegeben werden. Sollte Maven für Sie
neu sein, so fangen Sie an, den Beispielteil zu lesen. Die Referenz ist weniger als
Einführung gedacht, sondern mehr als Nachschlagewerk. Jedes Kapitel des
Referenzteils ziehlt genau auf ein Thema ab und geht hierbei auf die
tiefstmöglichen Details ein. So wird das Kapitel über die Erstellung von Plugins
anhand von einigen Beispielen und einer Anzahl Listen und Tabellen abgehandelt.
Beide Abschnitte bieten Erklärungen und doch werden grundverschiedene Wege
eingeschlagen. Während der beispielhafte Teil sich auf den Zusammenhang
innerhalb des Maven Projekt stützt, konzentriert sich der Referenzteil jeweils auf
ein einziges Thema. Sie können natürlich auch im Buch herumspringen; der
beispielhafte Teil ist in keiner Weise Voraussetzung für den Referenzteil, aber Sie
werden den Referenzteil besser verstehen, sollten Sie bereits den beispielhaften
Teil gelesen haben. Maven wird am Besten anhand von Beispielen gelernt, sobald
Sie die Beispiele durchgeabeitet haben werden Sie eine gute Referenzquelle
brauchen, um sich Maven Ihren Bedürfnissen anzupassen.

2. Ihr Feedback
Wir haben dieses Buch nicht geschrieben, um unserem Herausgeber ein Word
Dokument zu senden, eine Veröffentlichung zu feiern und einander zu
Beglückwünschen was für eine gute Arbeit wir geleistet haben. Dieses Buch ist
nicht "fertig", ja dieses Buch wird wohl nie "fertig" werden. Das behandelte Thema
ändert sich ständig, weitet sich aus; und so verstehen wir dieses Buch als ein
ständig weitergehender Dialog mit der Maven Community. Dieses Buch
herauszugeben bedeutet, dass die wahre Arbeit erst gerade begonnen hat, und Sie,
der Leser, spielen eine zentrale Rolle dieses Buch zu erweitern, verbessern und
xvi

Vorwort

aktuell zu halten. Sollten Sie etwas bemerken das fehlerhaft ist: ein
Rechtschreibfehler, schlechter Code, eine offenkundige Lüge, dann teilen Sie uns
dies mit! Schreiben Sie uns eine Email an: book@sonatype.com.
Die weitergehende Rolle dieses Buches ist abhängig von Ihrem Feedback. Wir sind
interessiert daran zu erfahren, was funktioniert und was nicht. Wir würden gerne
erfahren, sollte dieses Buch Informationen enthalten welche Sie nicht verstehen.
Ganz besonders wollen wir erfahren, sollten Sie den Eindruck haben dises Buch
wäre schrecklich. Positive und negative Rückmeldungen sind uns willkommen.
Wir nehmen uns das Recht heraus nicht jeder Meinung zuzustimmen, aber in
jedem Fall bekommen Sie eine gebührende Antwort.

3. Typographische Konventionen
Dieses Buch verwendet die folgenden typographischen Konventionen:

Kursiv
Wird für wichtige Begriffe, Programm- und Dateinamen, URLs, Ordner und
Verzeichnispfade und zur Hervorhebung/Einführung von Begriffen verwendet.

Nichtproportonalschrift
Wird für Programmcode verwendet (Java Klassennamen, -methoden,
Variablen, Properties, Datentypen, Datenbank Elemente, und andere
Codebeispiele welche in den Text eingestreut sind).

Fette Nichtproportonalschrift
Wird verwendet für Befehle welche Sie auf der Kommandozeile eingeben,
sowie um neue Codefragmente in fortlaufenden Beispielen hervorzuheben.

Kursive Nichtproportonalschrift
Wird verwendet um Ausgabetext zu kennzeichnen.

4. Konventionen in Bezug auf Maven

xvii

Vorwort

Dieses Buch folgt gewissen Konventionen bezüglich Namensgebung und
Schriftsatz bezüglich Apache Maven.

Compiler Plugin
Maven Plugins werden gross geschrieben.

Goal create
Maven Goal Namen werden in nichtproportionaler Schrift wiedergegeben.

"plugin"
Maven kreist stark um die Nutzung von Plugins, aber Sie werden keine
umfassende Definition von Plugin in einem Wörterbuch finden. Dieses Buch
benutzt den Terminus Plugin, da er einprägsam ist und auch weil er sich in der
Maven Community so eingebürgert hat.

Maven Lebenszyklus, Maven Standard Verzeichnis Layout, Maven Plugin,
Projekt Objekt Modell
Die Kernkonzepte von Maven werden im Text gross geschrieben, insbesondere
wenn darauf Bezug genommen wird.

Goal Parameter
Ein Parameter eines Maven Goal wird in nichtproportionalschrift
wiedergegeben.

Phase compile
Lebenszyklusphasen werden in nichtproportionalschrift wiedergegeben.

5. Danksagung
Sonatype möchte sich insbesondere bei allen Mitwirkenden bedanken: die folgende
Liste ist in keiner Weise abschliessend oder vollständig und alle haben mitgewirkt
um die Qualität dieses Werkes zu verbessern. Vielen Dank an Mangalaganesh
Balasubramanian, Bertrand Florat, Chad Gorshing, Ali Colabawala, Bozhidar
Batzov sowie Mark Stewart. Besonderen Dank auch an Joel Costigliola für die
Hilfe und Korrektur des Kapitels bezüglich Spring Web. Stan Guillory war schon

xviii

Vorwort

so etwas wie ein Teilautor, zählt man die grosse Zahl der Korrekturen und
Verbesserungsvorschläge welcher er einbrachte. Vielen Dank Stan. Speziellen
Dank auch an Richard Coatsby von Bamboo der die Rolle des einstweiligen
Grammatik-Beraters aufgenommen hat.
Vielen Dank an alle partizipierenden Teilautoren einschliesslich Eric Redmond.
Vielen Dank auch an die folgenden Mitwirkenden welche Fehler entweder in Form
einer Email oder zum zugehörigen Get Satisfaction Site gemeldet haben: Paco
Soberón, Ray Krueger, Steinar Cook, Henning Saul, Anders Hammar,
"george_007", "ksangani", Niko Mahle, Arun Kumar, Harold Shinsato, "mimil",
"-thrawn-", Matt Gumbley. Sollten Sie Ihren Get Satisfaction Benutzernamen in
dieser Liste aufgeführt sehen und würden diesen gerne durch Ihren Namen ersetzt
wissen, so senden Sie uns eine kurze Mail an book@sonatype.com.

xix

Chapter 1. Einführung von Apache Maven
Es gibt zwar schon eine Reihe Online Veröffentlichungen zum Thema Apache
Maven, aber was bis heute fehlt, ist eine umfassende, gut geschriebenen
Einführung von Maven, welche zugleich als altgediente Referenz herhalten kann.
Was wir hier versucht haben, ist eine solche gesamthafte Einführung gepaart mit
einer umfassenden Referenz zu erstellen.

1.1. Maven ... Was ist das?
Die Antwort auf diese Frage hängt ganz von Ihrer Perspektive ab. Die große
Mehrheit der Benutzer wird Maven als "Build"-Werkzeug einordnen: ein
Werkzeug um aus Quellcode einsatzfähige Artefakte (Programme) zu erzeugen.
Build Ingenieure und Projektmanager mögen Maven als etwas umfassenderes
sehen: ein (technisches) Projektmanagement-Tool. Wo liegt der Unterschied? Ein
Build-Werkzeug wie Ant ist ausschließlich auf die Vorverarbeitung,
Kompilierung, Prüfung und Verteilung ausgelegt. Ein Projekt-Management-Tool
wie Maven liefert eine Obermenge von Funktionen welche in einem Build- und
Paketier-Werkzeug zur Anwendung kommen. Neben der Bereitstellung von Build
Funktionalitäten, bietet Maven auch die Möglichkeit Berichte/Auswertungen
(Reports) anzufertigen, Websites zu generieren und den Kontakt zwischen den
Mitgliedern einer Arbeitsgruppe/eines Teams zu ermöglichen.
Hier eine formale Definition von Apache Maven: Maven ist ein
Projektmanagement-Tool welches ein umfassendes Projektmodell beinhaltet und
eine Reihe von Normen bereitstellt. Darüber hinaus verfügt es über einen
definierten Projekt-Lebenszyklus, ein Abhängigkeits-Management-System sowie
Logik, welche die Ausführung von Plugin-Goals in definierten Phasen eines
Lebenszykluses ermöglicht. Wenn Sie Maven einsetzen, beschreiben Sie Ihr
Projekt in einem genau definierten Projekt Objekt Modell, im weiteren Text POM
genannt. Maven kann dann auf dieses Modell überspannende Regelwerke aus der
Menge gemeinsam genutzter (oder auch massgeschneiderter) Plugins anwenden.
Lassen Sie sich nicht von der Tatsache dass Maven ein "Projektmanagement"

1

Einführung von Apache Maven

Werkzeug darstellt, erschrecken. Sollten Sie lediglich nach einem Build-Tool
Ausschau gehalten haben, so wird Maven Ihnen dies ebenfalls bieten. In der Tat,
die ersten Kapitel dieses Buches befassen sich mit dem häufigsten
Anwendungsfall: Der Verwendung von Maven um Ihr Projekt zu kompilieren,
testen und zu verteilen.

1.2. Konvention über Konfiguration
Konvention über Konfiguration ist ein einfaches Konzept: Systeme, Bibliotheken
und Frameworks sollten von vernünftige Standardwerten ausgehen, ohne unnötige
Konfigurationen zu benötigen - Systeme sollten "einfach funktionieren". Gängige
Frameworks wie Ruby on Rails und EJB3 haben damit begonnen, sich an diesen
Grundsätzen zu orientieren. Dies in Reaktion auf die Komplexität der
Konfiguration von Frameworks wie etwa der anfänglichen EJB 2.1
Spezifikationen. Das Konzept 'Konvention über Konfiguration' wird am Beispiel
der EJB 3 Persistenz schön veranschaulicht: alles, was Sie tun müssen, um ein
bestimmtes Bean persistent zu speichern ist, dieses mit einer @Entitiy-Annotation
zu versehen. Das Framework übernimmt Tabellen-und Spaltennamen basierend auf
den Namen der Klasse und den Namen der Attribute. Es besteht die Möglichkeit,
mittels sogenannter 'Hooks' - wenn nötig - die gesetzten Standardwerte zu
übersteuern. In den meisten Fällen werden Sie feststellen, dass der Einsatz der vom
Framework bereitgestellten Namen zu einer schnelleren Projektdurchführung führt.
Maven greift dieses Konzept auf und stellt vernünftige Standard-Verhalten für
Projekte bereit. Ohne weitere Anpassungen, wird davon ausgegangen, dass sich
Quellcode im Verzeichnis ${basedir}/src/main/java und Ressourcen sich im
Verzeichnis ${basedir}/src/main/resources befinden. Von Tests wird davon
ausgegangen, dass diese sich im Verzeichnis ${basedir}/src/test befinden, sowie
ein Projekt standardmäßig ein JAR-Archive bereitstellt. Maven geht davon aus,
dass Sie den kompilierten Byte-Code unter ${basedir}/target/classes ablegen
wollen und anschließend ein ausführbares JAR-Archive erstellen, welches im
Verzeichnis ${basedir}/target abgelegt wird. Zwar mag diese Lösung trivial
anmuten, jedoch bedenken Sie bitte die Tatsache, dass die meisten Ant-basierten
Projekte die Lage dieser Verzeichnisse in jedem Teilprojekt festlegen müssen. Die

2


Umsetzung von Konvention über Konfiguration in Maven geht noch viel weiter als
nur einfache Verzeichnis Standorte festzulegen, Maven-Core-Plugins kennen ein
einheitliches System von Konventionen für die Kompilierung von Quellcode, der
Paketierung sowie Verteilung der Artefakten, der Generierung von
(Dokumentations-) Web-Seiten, und vielen anderen Prozessen. Die Stärke von
Maven beruht auf der Tatsache, dass Maven mit einer 'vorbestimmten Meinung'
ausgelegt ist: Maven hat einen definierten Lebenszyklus sowie eine Reihe von
Plugins welche unter gemeinsamen Annahmen in der Lage sind, Software zu
erstellen. Sollten Sie nach den Konventionen arbeiten, erfordert Maven fast keinen
Aufwand - einfach Ihre Quellen in das richtige Verzeichnis legen - Maven
kümmert sich um den Rest.
Ein Nachteil der Verwendung von Systemen welche dem Grundsatz der
Konvention über Konfiguration folgen ist, dass Endbenutzer oftmals die Gefahr
sehen, dass sie gezwungen werden eine bestimmte Methode anzuwenden - einem
bestimmten Ansatz folgen müssen. Zwar ist es sicherlich richtig, dass der Kern von
Maven auf einigen wenigen Grundannahmen basiert, welche nicht in Frage gestellt
werden sollten, dennoch kann man die meisten Vorgaben auf die jeweilig
vorherrschenden Bedürfnisse anpassen und konfigurieren. So kann zum Beispiel
die Lage des Projekt-Quellcodes sowie dessen Ressourcen konfiguriert werden,
oder die Namen der resultierenden JAR-Archive angepasst werden. Durch die
Entwicklung von massgefertigten Plugins, kann fast jedes Verhalten an die
Bedürfnisse Ihrer Umgebung angepasst werden. Sollten Sie der Konvention nicht
folgen wollen, ermöglicht Maven es Ihnen Voreinstellungen anzupassen um Ihren
spezifischen Anforderungen Rechnung zu tragen.

1.3. Die gemeinsame Schnittstelle
In der Zeit vor Maven, das eine gemeinsame Schnittstelle für den Build von
Software bereitstellte, hatte gewöhnlich jedes einzelne Projekt eine Person, welche
sich der Verwaltung des völlig eigenen Build Systems widmete. Entwickler
mussten einige Zeit aufwenden, um neben der tatsächlichen Entwicklung
herauszufinden, welche Eigenheiten beim Build einer neuen Software zu
berücksichtigen waren, zu welcher sie beitragen wollten. Im Jahr 2001, gab es

3


völlig unterschiedliche Build Konzepte/Systeme welche für den Build eines
Projekts wie Turbine, POI oder Tomcat zur Anwendung kamen. Jedesmal, wenn
ein neues Source Code-Analyse-Tool zur statischen Analyse von Quellcode
veröffentlicht wurde, oder wenn jemand ein neues Unit-Test Framework herausgab
welches man einsetzen wollte/sollte, musste man alles stehen und liegen lassen, um
herauszufinden, wie dieses neue Werkzeug in das Projekt und dessen Build
Umgebung einzupassen wäre. Wie konnte man Unit-Tests laufen lassen? Es gab
tausend verschiedene Antworten. Dieses Umfeld war geprägt von tausenden
endlosen Auseinandersetzungen bezüglich der 'richtigen' Werkzeuge und
Build-Vorgehen. Das Zeitalter vor Maven war ein Zeitalter der Ineffizienz: das
Zeitalter der "Build-Ingenieure".
Heute setzen die meisten Open-Source-Entwickler bereits auf Maven, oder nutzen
dieses um neue Software-Projekten aufzusetzen. Dieser Übergang ist weniger ein
Wechsel von einem Build Werkzeug zu einem anderen, sondern viel mehr eine
Entwicklung, hin zum Einsatz einer gemeinsamen Build-Schnittstelle für Projekte.
So wie Software-Systeme modularer wurden, wurden Build Werkzeuge komplexer
und die Zahl der (Teil-)Projekte wuchs in den Himmel. In der Zeit vor Maven,
mussten Sie, wollten Sie etwa ein Projekt wie Apache ActiveMQ oder Apache
ServiceMix aus Subversion auschecken und aus den Quellen erstellen, mit
mindestens einer Stunde Aufwand rechnen, die Sie damit verbrachten
herauszufinden, wie das Build-System des einzelnen Projekts funktionierte. Was
waren die Voraussetzungen, um das Projekt zu builden? Welche Bibliotheken
muss man herunterladen? Wo bekomme ich diese? Welche Targets kann ich im
Build ausführen? Im besten Fall dauerte es ein paar Minuten um herauszufinden
wie ein neues Projekt zu builden war, - und im schlimmsten Fall (wie die alte
Servlet-API-Umsetzung des Jakarta-Projekts), war ein Projekt aufbauen so
schwierig, das es mehrere Stunden dauerte nur um an einen Punkt zu gelangen, an
dem ein neuer Mitarbeiter den Quellcode bearbeiten konnte und das Projekt
kompilierte. Heutzutage machen Sie einen Projekt Check-Out und führen mvn
install aus.
Während Maven eine Reihe von Vorteilen einschließlich der Verwaltung von
Abhängigkeiten und Wiederverwendung von gemeinsamer Logik zum Build durch
Plugins bietet, ist der Hauptgrund für den Erfolg der, dass es gelungen ist eine

4


einheitliche Schnittstelle für den Build von Software bereitzustellen. Wenn Sie
sehen, dass ein Projekt wie Apache Wicket Maven verwendet, können Sie davon
ausgehen, dass Sie in der Lage sein werden, Projekt ohne weiten Aufwand
auszuchecken und aus den Quellen mittels mvn zu bauen und zu installieren. Sie
wissen, wo der Zündschlüssel hinkommt, Sie wissen, dass das Gas-Pedal auf der
rechten Seite und die Bremse auf der Linken ist.

1.4. Universelle Wiederverwendung durch
Maven-Plugins
Der Herzstück von Maven ist ziemlich dumm. Es weiss nicht viel mehr als ein paar
XML-Dokumenten zu parsen sowie einen Lebenszyklus und ein paar Plugins zu
verwalten. Maven wurde so konzipiert, dass die meiste Verantwortung auf eine
Anzahl Maven-Plugins delegiert werden kann, welche den Lebenszyklus von
Maven beeinflussen sowie gewisse Goals erreichen können. Der Großteil der
Arbeit geschieht in Maven Goals. Hier passieren Dinge wie die Kompilierung von
Quellcode, der Paketierung von Bytecode, die Erstellung von Websites, und jede
andere Aufgabe die um einen Build zu erfüllen notwenig ist. Die Maven
Installation nach dem Download von Apache weiß noch nicht viel über die
Paketierung eines WAR-Archivs oder dem Ausführen eines JUnit-Tests; der größte
Teil der Intelligenz von Maven ist in den Plugins enthalten und diese bezieht
Maven aus dem Maven-Repository. In der Tat, das erste Mal, als Sie einen Aufruf
wie z.B. mvn install auf Ihrer neuen Maven Installation absetzten, holte sich
Maven die meisten der Core Maven Plugins aus dem zentralen Maven-Repository.
Das ist mehr als nur ein Trick, um die Download-Größe von Maven in der
Verteilung zu beeinflussen, dieses Verhalten ist es, das es erlaubt, durch die
Erweiterung eines Plugins die Fähigkeiten des Builds zu verändern. Die Tatsache,
dass Maven sowohl die Abhängigkeiten wie auch die Plugins aus einem
Remote-Repository lädt ermöglicht universelle Wiederverwendung von
Build-Logik.
Das Maven Surefire Plugin ist das Plugin, welches für die Ausführung von
Unit-Tests verantwortlich zeichnet. Irgendwo zwischen Version 1.0 und der aktuell

5


verbreiteten Version hat jemand beschlossen, dieses neben der Unterstützung von
JUnit auch um die Unterstützung für das TestNG Unit-Test Framework zu
erweitern. Dies geschah in einer Art und Weise, dass die Abwärtskompatibilität
erhalten blieb. Für die Benutzer des Surefire Plugin im Einsatz von JUnit3 Tests
veränderte sich nichts, weiterhin werden die Tests kompiliert und ausgeführt, wie
dies zuvor der Fall war. Aber Sie erhalten eine neue Funktionalität, denn sollten
Sie nun Unit Tests nach dem TestNG Framework ausführen wollen, so haben Sie
nun auch diese Möglichkeit, dank der Bemühungen der Maintainer des Surefire
Plugin. Das Plugin erhielt auch die Fähigkeit annotierte JUnit4 Unit Tests zu
unterstützen. Alle diese Erweiterungen wurden bereitgestellt, ohne dass Sie Maven
aktiv aktualisieren, oder neue Software installieren mussten. Und ganz zentral, Sie
mussten nichts an Ihrem Projekt ändern, abgesehen von einer Versionsnummer für
ein Plugin in einem POM.
Es ist dieser Mechanismus welche sich auf wesentlich mehr als nur das Surefire
Plugin auswirkt: Projekte werden mittels einem Compiler Plugin kompiliert,
mittels JAR-Plugin in JAR-Archive gepackt, es gibt es Plugins zum Erstellen von
Berichten, Plugins zur Ausführung von JRuby und Groovy-Code, sowie Plugins
zum Veröffentlichen von Websites auf Remote-Servern. Maven hat gemeinsame
Aufgaben in Plug-Ins herausgelöst welche zentral gewartet sowie universell
eingesetzt werden. Wann immer Veränderungen in einem Bereich des Buildens
umgesetzt werden, wann immer ein neues Unit-Test Framework freigegeben oder
ein neues Werkzeug bereit gestellt wird. Sie sind nicht gezwungen, diese
Änderungen in ihren Build einzupflegen um dies zu unterstützen. Sie profitieren
von der Tatsache, dass Plugins von einem zentral gewarteten Remote-Repository
heruntergeladen werden. Das ist die wahre Bedeutung von universeller
Wiederverwendung durch Maven Plugins.

1.5. Konzeptionelles Modell eines "Projekts"
Maven unterhält ein (abstraktes) Modell eines Projekts, Sie verarbeiten also nicht
nur Quellcode Dateien in Binärdateien, Sie entwickeln zugleich eine Beschreibung
des Software-Projekts und ordnen diesem eine Reihe einzigartiger Koordinaten zu.
Sie beschreiben die Attribute des Projekts: Wie ist die Projektlizenzierung

6


geregelt? Wer entwickelt und trägt zum Projekt bei? Zu welchen anderen Projekten
bestehen Abhängigkeiten? Maven ist mehr als nur ein "Build-Tool", es ist mehr als
nur eine Verbesserung von Werkzeugen wie make™ und Ant™; es ist eine
Plattform, umfasst eine neue Semantik bezüglich Software-Projekten und
Software-Entwicklung. Diese Definition eines Modells für jedes Projekt
ermöglicht Funktionen wie:

Dependency Management / Abhängigkeits Verwaltung
Da ein Projekt einzigartig mittels einer Gruppenkennung (groupId),
Artefaktenkennung (artifactId) und Version (version) identifiziert wird, ist nun
möglich, diese Koordinaten zur Abhängigkeitsverwaltung einzusetzen.

Remote-Repositories
Mit Blick auf das Abhängigkeitsmanagement ist es nun möglich diese im
Maven Projekt Objekt Modell eingeführten Koordinaten einzusetzen um Maven
Repositorien aufzubauen.

Universelle Wiederverwendung der Build-Logik
Plugins werden ausgerichtet auf das Projekt Objekt Model (POM) gebaut, sie
sind nicht dafür ausgelegt auf bestimmte Dateien an bestimmten Orten
zuzugreifen. Alles wird in das Modell abstrahiert, Plugin-Konfiguration und
Anpassung geschieht im Modell.

Tool Portabilität / Integration
Werkzeuge wie Eclipse, NetBeans oder IntelliJ haben jetzt einen gemeinsamen
Ort um auf Projektinformationen zuzugreifen. Vor dem Aufkommen von
Maven, gab es für jede IDE eine spezifische Art und Weise in welcher diese
Daten abgelegt wurden, was im Wesentlichen einem benutzerdefinierten POM
entspricht. Maven standardisiert diese Beschreibung und während jeder IDE
weiterhin deren eigenes Datenablagesystem unterhalten kann, lässt sich dieses
nun leicht aus dem Modell heraus generieren.

Einfache Suche und Filterung von Projekt-Artefakten
Werkzeuge wie Nexus ermöglichen es Ihnen schnell und einfach Archive auf
der Basis der im POM enthaltenen Daten zu indexieren und zu durchsuchen.

7


Maven hat eine Grundlage für die Anfänge einer konsistenten semantischen
Beschreibung eines Software-Projekts geschaffen.

1.6. Ist Maven eine Alternative zu XYZ?
Natürlich, Maven stellt eine Alternative zu Ant dar, aber Apache Ant ist nach wie
vor ein großartiges, weit verbreitetes Werkzeug. Es stellt seit Jahren den
amtierende Champion der Java Build Tools, und Sie können auch weiterhin
Ant-Build-Skripte einfach in Ihr Maven Projekt integrieren. Das ist auch eine
gebräuchliche Art, Maven einzusetzen. Andererseits, jetzt da mehr und mehr
Open-Source-Projekte sich auf Maven zubewegen und Maven als Projekt
Management Plattform einsetzen, haben aktive Entwickler begonnen zu erkennen,
dass Maven nicht nur die Aufgabe der Build Verwaltung unterstützt, sondern
insgesamt zur Förderung einer gemeinsamen Schnittstelle zwischen Entwicklern
und Software Projekte beiträgt. Maven hat viele Ausprägungen eine Plattform als
nur eines Werkzeugs. Wenn Sie die Auffassung vertreten würden, Maven als eine
Alternative zu Ant anzusehen, so würden Sie Äpfel mit Birnen vergleichen. Maven
umfasst mehr als nur ein einen Werkzeugkasten um Projekte zu Builden.
Dies ist das zentrale Argument, welches alle Vergleiche der Art Maven/Ant,
Maven/Buildr, Maven/Gradle unerheblich macht. Maven ist nicht bestimmt von
der Mechanik Ihres Build-Systems, es fusst nicht auf dem Skripting der
verschiedenen Aufgaben Ihres Builds, sondern es geht weit mehr um die
Förderung einer Reihe von Standards, einer gemeinsamen Schnittstelle, eines
Leben-Zykluses, einem Standard-Repository Format, einem Standard-Verzeichnis
Layout, usw. Es geht sicherlich nicht darum, welches POM-Format zum Einsatz
kommt, ob XML, YAML, Ruby oder Maven. Maven bietet weit mehr als dies:
Maven und bezieht sich auf viel mehr als nur das Werkzeug. Wenn dieses Buch
von Maven spricht, so bezieht sich dies auf die Zusammenstellung von Software,
Systemen und Standards, welche Maven unterstützt. Buildr, Ivy, Gradle alle diese
Werkzeuge interagieren mit den Repository-Format welches zu definieren Maven
beigetragen hat. Sie könnten genauso einen Build auf der Basis von Buildr einzig
unter Zuhilfenahme von einem Tool wie Nexus aufbauen, Nexus wird in
vorgestellt in Kapitel 16: Repository-Manager.

8


Während Maven eine Alternative für viele dieser Tools darstellt, muss die
Gemeinschaft der Open Source Entwickler darüber hinaus kommen können,
Technologie als ein kontinuierliches Nullsummenspiel zwischen unfreundlichen
Konkurrenten in einer kapitalistischen Wirtschaft zu sehen. Dies mag im
Wettbewerb von Großunternehmen und Ihrem Bezug zu einander sinnvoll
erscheinen, hat aber wenig Relevanz auf die Art und Weise, wie
Open-Source-Communities arbeiten. Die Überschrift "Wer gewinnt? Ant oder
Maven?" ist nicht sehr konstruktiv. Zwingen Sie uns, diese Frage zu beantworten,
werden wir uns definitiv auf die Seite von Maven schlagen und darlegen, dass
Maven eine gegenüber Ant überlegene Alternative darstellt die darüberhinaus die
Grundlage für eine Technologie des Buildes legt. Gleichzeitig bitten wir zu
berücksichtigen, dass die Grenzen von Maven in ständiger Bewegung sind, die
Maven Gemeinde ist immerzu versucht, neue Wege zu mehr Ökumene, mehr
Interoperabilität, größerer Gemeinschaft zu schaffen. Die Kernkomponenten von
Maven sind der deklarative Build, die Abhängigkeitsverwaltung (Dependency
Management), Repository Verwaltung und breite Wiederverwendbarkeit durch den
Einsatz von Plugins. Es sind aber die spezifische Inkarnationen dieser Ideen zu
einem gegebenen Zeitpunkt weniger wichtig, als das Ziel dass die
Open-Source-Community in Zusammenarbeit zur Verringerung der Ineffizienz von
"Enterprise Scale Builds" beizutragen.

1.7. Ein Vergleich von Maven und Ant
Während der vorangegangene Abschnitt Ihnen verständlich gemacht haben sollte,
dass die Autoren dieses Buches keinerlei Interesse an der Schaffung oder
Vertiefung einer Fehde zwischen Apache Ant und Apache Maven haben, ist uns
die Tatsache bewusst, dass die meisten Organisationen eine Entscheidung
zwischen Ant und Maven treffen (müssen). In diesem Abschnitt werden wir daher
diese beiden Werkzeuge gegenüberstellen.
Ant läuft beim Build-Prozess zu seiner vollen Grösse auf: Es ist ein Build-System
nach dem Vorbild von make mit Targets und Abhängigkeiten. Jeder Target besteht
aus einer Reihe von Anweisungen, die in XML beschrieben werden. Es gibt eine
Task copy, eine Task javac sowie eine Task JAR. Wenn Sie Ant benutzen, müssen

9

Sie Ant mit der speziellen, spezifischen Anweisungen für die Zusammenstellung
und dem Packaging Ihres Projektes aufrufen. Sehen Sie sich das folgende Beispiel
einer einfachen Ant build.xml-Datei an:

Example 1.1. Eine einfache Ant build.xml-Datei
<project name="my-project" default="dist" basedir=".">
<description>
simple example build file
</description>

<property name="src" location="src/main/java"/>
<property name="build" location="target/classes"/>
<property name="dist" location="target"/>

<target name="init">

<tstamp/>

<mkdir dir="${build}"/>
</target>

<target name="compile" depends="init"
description="compile the source " >

<javac srcdir="${src}" destdir="${build}"/>
</target>

<target name="dist" depends="compile"
description="generate the distribution" >

<mkdir dir="${dist}/lib"/>


<jar jarfile="${dist}/lib/MyProject-${DSTAMP}.jar" basedir="${build}"/>
</target>

<target name="clean"
description="clean up" >

<delete dir="${build}"/>
<delete dir="${dist}"/>
</target>
</project>

An diesem einfachen Beispiel eines Ant Skriptes, können Sie sehen, wie genau
man definieren muss, was man von Ant erwartet. Ein Target ist javac, hier werden

10


die Quelldateien in Binärdaten verarbeitet, dabei ist es wichtig, dass man genau
angibt, wo die Quell- sowie Zieldateien abgelegt werden (/src/main/java resp.
/target/classes). Ebenfalls müssen Sie Ant anweisen, aus den resultierenden
Dateien ein JAR-Archiv zu erstellen. Während einige der neueren Entwicklungen
dazu beitragen, dass Ant weniger prozedural orientiert arbeitet, ist die
Entwickler-Erfahrung dennoch die, einer in XML abgefassten prozeduralen
Programmiersprache.
Vergleichen Sie das Vorgehen von Maven mit dem vorigen Beispiel: In Maven,
um ein JAR-Archive aus einer Reihe von Java Quellcode Dateien zu erstellen, ist
alles, was Sie tun müssen, ein einfaches POM (pom.xml Datei) zu generieren.
Platzieren Sie den Quellcode in ${basedir}/src/main/java und führen Sie dann
mvn install von der Befehlszeile aus . Das Beispiel der Maven pom.xml Datei,
welches zum selben Ergebnis führt wie zuvor das Ant-Skript sehen Sie unten.

Example 1.2. Muster einer Maven pom.xml-Datei
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>my-project</artifactId>
<version>1.0</version>
</project>

Das ist alles was Sie in der zugehörigen pom.xml Datei benötigen. Der Aufruf von
mvn install wird die Resourcen sowie Quelldateien kompilieren, bestehende
Unit-Tests ausführen, JAR-Archive erstellen und dieses in einem lokalen
Repository anderen Projekten zur Verfügung stellen. Ohne die pom.xml Datei
abzuändern, können Sie durch den Aufruf von mvn site im Zielverzeichnis eine
index.html wiederfinden, welche den Link zu einer Dokumentations-Web-Seite auf
der Basis von JavaDoc sowie einigen Standard Reports bereitstellt.
Zugegeben, dies ist das einfachste, mögliche Beispiel-Projekt. Ein Projekt, das nur
Quellcode enthält und ein JAR-Archive erzeugt. Ein Projekt welches der Maven
Konvention unterliegt und keinerlei Abhängigkeiten oder Anpassungen
berücksichtigt. Sobald wir die Verhaltensweisen der Plugins anpassen wird unsere
pom.xml Datei wachsen. In den grössten Projekten werden Sie komplexe Maven

11


POMs finden, welche eine grosse Anzahl Plugin-Anpassungen sowie
Abhängigkeitserklärungen enthalten. Aber, selbst wenn das POM Ihres Projekts
erheblich wächst, enthält dies eine ganz andere Art von Daten und Informationen
denn das Skript einer entsprechenden Ant-Datei. Maven POMs enthalten
Deklarationen wie: "Dies ist eine JAR-Projekt", und "Der Quellcode ist unter
/src/main/java abgelegt". Wohingegen Ant-Build-Dateien explizite Anweisung
enthalten: "Dies ist ein Projekt", "Die Quelle ist in /src/main/java", "javac gegen
dieses Verzeichnis ausführen", "Ablegen der Ergebnisse in /target/classses",
"Erstellen eines JAR-Archives aus der. ...". Wo Ant genauen Prozess-Anweisungen
bedurfte, gab es etwas innerhalb des Maven Builds, das einfach "wusste", wo der
Quellcode zu finden ist und wie dieser zu verarbeiten ist.
Die Unterschiede zwischen den Ant und Maven in diesem Beispiel sind:

Apache Ant

• Ant kennt keine formalen Konventionen bezüglich einer gemeinsamen
Projekt Verzeichnis-Struktur. Sie müssen Ant genau sagen, wo sich die
Quelldateien befinden und wo die Ausgabe abgelegt werden soll. Informelle
Konventionen haben sich im Laufe der Zeit herausgebildet, aber diese
wurden nicht im Produkt kodifiziert.

• Ant ist Prozedural, Sie müssen Ant genau sagen, was zu tun ist und wann
dies zu tun. Sie mussten definieren: erst kompilieren, dann kopieren, dann
paketieren.

• Ant kennt keinen Lebenszyklus, Sie mussten Targets definieren und deren
Abhängigkeiten. Sie mussten die Abfolge der Schritte manuell für jeden
Target festlegen.

Apache Maven

• Maven arbeitet nach Konventionen. Da Sie diese beachteten, wusste Maven
wo Ihr Quellcode sich befand. Es stellt den Bytecode unter target/classes
und es erzeugte ein JAR-Archive in /target.

12


• Maven ist deklarative. Alles was Sie tun musste, war eine pom.xml Datei zu
erzeugen sowie Ihre Quelle im Standard-Verzeichnis ablegen. Maven
kümmerte sich um den Rest.

• Maven kennt einen Lebenszyklus, welchen Sie mit dem Aufruf von mvn
install angestossen haben. Dieser Aufruf bringt Maven dazu, eine Abfolge
von Schritten abzuarbeiten, bis das Ende des Lebenszykluses erreicht ist. Als
Nebeneffekt dieser Reise durch den Lebenszyklus führt Maven eine Reihe
von Standard-Plugin-Goals aus, diese erledigen Arbeiten wie z.B.
kompilieren oder dem Erstellen eines JAR-Archives.
Maven hat eine eingebaute Intelligenz bezüglich der gemeinsamen
Projektaufgaben in Form von Maven-Plugins. Sollten Sie Unit Tests ausführen
wollen, ist alles was Sie tun müssen, die Tests zu schreiben und unter
${basedir}/src/test/java abzulegen, führen Sie eine Test bezogene
Abhängigkeit zu entweder TestNG oder JUnit ein, und starten Sie mvn test.
Sollten Sie anstelle eines JAR-Archives eine Web Anwendung erstellen, so ist
alles was Sie tun müssen den Projekttyp auf "war" umstellen und Ihr
Applikationsverzeichnis (docroot) auf ${basedir}/src/main/webapp setzen. Klar,
können Sie all dies auch mit Ant bewerkstelligen, aber Sie werden alle
Anweisungen von Grund auf festhalten. In Ant würden Sie erst einmal
herausfinden, wo die JUnit-JAR-Datei sich befindet, dann müssten Sie einen
Klassenpfad erstellen welcher auch die JUnit-Archive Datei enthält, und
anschliessend Ant mitteilen wo sich der Quellcode befindet. Schliesslich würden
Sie einen Target erstellen die Quellen der Test Dateien zu kompilieren und zu
guter Letzt die Tests mit JUnit auszuführen.
Ohne Unterstützung von Technologien wie antlibs und Ivy (und auch mit diesen
unterstützenden Technologien) stellt sich bei Ant das Gefühl eines prozeduralen
Build Ablaufs ein. Eine effiziente Zusammenstellung einiger Maven POMs in
einem Projekt welches sich an die Maven-Konventionen hält erzeugt überraschend
wenig XML im Vergleich zur Ant-Alternative. Ein weiterer Vorteil von Maven ist
die Abhängigkeit von weithin benutzten Maven-Plugins. Heutzutage benutzt jeder
das Maven Surefire Plugin für Unit-Tests, sobald jemand ein weiteres Unit Test
Framework einbindet, können Sie neue Fähigkeiten in Ihrem eigenen Build durch

13


die einfache Änderung der Version eines einzelnen, bestimmten Maven Plugins
nutzen.
Die Entscheidung über die Verwendung Maven oder Ant ist heutzutage nicht
binär. Ant hat noch immer einen Platz in in komplexen Builds. Wenn Ihr aktueller
Build-Prozess einige sehr individuelle Prozesse enthält, oder wenn Sie etliche
Ant-Skripte geschrieben haben um einen bestimmten Prozess in einer bestimmten
Weise, die sich nicht an die Normen Maven hält, abzudecken, können Sie diese
Skripte dennoch mit Maven abarbeiten. Ant wird als Kernkomponente in Form
eines Plugins von Maven zur Verfügung gestellt. Benuzerdefinierte Maven-Plugins
können in Ant geschrieben werden und Maven Projekte können so konfiguriert
werden, das Ant-Skripte innerhalb des Maven-Projekt-Lebenszykluses abgearbeitet
werden.

1.8. Zusammenfassung
Diese Einführung wurde absichtlich kurz gehalten. Wir haben Ihnen umrissen, was
Maven ist und wie es zu einem guten Build-Prozess beiträgt, sowie über die Zeit
hinweg diesen verbessern hilft. Im nächste Kapitel werden wir am Beispiel eines
einfachen Projektes aufzeigen welche phänomenalen Aufgaben mit dem
kleinstmöglich Aufwand an Konfiguration geleistet werden können.

14

Chapter 2. Installieren und Ausführen von
Maven
Dieses Kapitel enthält detaillierte Anweisungen für die Installation von Maven auf
einer Reihe von unterschiedlichen Plattformen. Statt ein bestimmtes Mass der
Vertrautheit mit der Installation von Software und dem Einstellen von
Umgebungsvariablen vorauszusetzen, haben wir uns entschieden, so detailliert wie
möglich zu sein, um Probleme welche von unvollständigen Installation herrühren
von vornherein zu minimieren. die einzige Voraussetzung welche angenommen
wird ist die, einer bestehenden, geeigneten und vollständigen Java Umgebung,
eines Java Development Kit (JDK). Sollten Sie nur Interesse an der Installation
haben, so können Sie nach dem Lesen der Abschnitte "2.2 Herunterladen von
Maven" sowie "2.3 Installation von Maven" zu den weiterführenden Kapiteln des
Buches übergehen. Wenn Sie an einer detaillierten Beschreibung interessiert sind,
so gibt Ihnen dieses Kapitel die entsprechenden Informationen sowie eine
Erklärung der Bedeutung der Apache Software License, Version 2.0.

2.1. Überprüfen der Java-Installation
Obschon Maven auch auf Java 1.4 unterstützt ist, geht dieses Buch davon aus, dass
sie mindestens auf Java 5 aufsetzen. Wählen Sie den neusten stabilen JDK welcher
für Ihre Plattform erhältlich ist. Alle in diesem Buch aufgeführten Beispiele sind
unter Java 5 oder Java 6 lauffähig.
% java -version
java version "1.6.0_02"
Java(TM) SE Runtime Environment (build 1.6.0_02-b06)
Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing)

Maven ist unter allen Java-kompatibel zertifiziert Entwicklungsumgebungen,
sowie einigen weiteren, nicht-zertifizierten Implementierungen von Java lauffähig.
Die Beispiele in diesem Buch wurden gegen die offizielle Java Development Kit
Implementation wie diese von Sun Microsystems Webseite (http://java.sun.com)

15

Installieren und Ausführen von Maven

heruntergeladen werden kann, geschrieben und getestet. Sollten Sie mit einer
Linux-Distribution arbeiten, müssen Sie eventuell die Java
Entwicklungsumgebung selbst herunterladen und installieren. Bitte stellen Sie
sicher, dass diese auch zum Einsatz kommt: durch Aufruf von "java -fullversion ".
Nun, da Sun Microsystem den Quellcode von Java unter einer Open Source Lizenz
offengelegt hat, tritt diesbezüglich hoffentlich schon bald eine Besserung ein und
es werden auch auf puristisch Linux-Distributionen die originalen Sun JRE sowie
JDKs installiert. Bis zu diesem Tag müssen Sie selbst Hand anlegen, Java
herunterladen und installieren.

2.2. Herunterladen von Maven
Sie können Maven von der Apache Maven-Projekt-Website unter
http://maven.apache.org/download.html herunterladen.
Beim Herunterladen von Maven, wählen Sie die neuste Version von Apache
Maven vom Website. Die aktuell neuste Version zur Zeit als dieses Buch
geschrieben wurde war Maven 2.0.9. Sollten Sie die Apache Software Lizenz noch
nicht kennen, so machen sie sich - vor dem Einsatz des Produktes - mit deren
Bedingungen vertraut. Weitergehende Informationen diesbezüglich finden Sie in
Abschnitt "2.8 Die Apache Software Lizenz".

2.3. Installation von Maven
Die Unterschiede zwischen den Betriebssystemen wie Mac OS X und Microsoft
Windows sind gross, daneben gibt auch subtile Unterschiede zwischen den
verschiedenen Versionen von Windows oder Varianten von Linux zu beachten.
Zum Glück ist der Prozess der Installation von Maven auf all diesen
Betriebssystemen relativ einfach und schmerzlos. Die folgenden Abschnitte geben
einen Überblick über die empfohlene Best-Practice der Installation von Maven
unter einer Vielzahl von Betriebssystemen.

16


2.3.1. Maven Installation unter Mac OSX
Am Anfang benötigen Sie zunächst die Software, diese bekommen Sie unter:
http://maven.apache.org/download.html. Laden Sie die aktuelle Version von
Maven in einem für Sie passenden Format herunter. Wählen Sie einen geeigneten
Platz als "Heimat" und entpacken Sie das Archiv dort. Wenn Sie zum Beispiel das
Verzeichnis /usr/local/apache-maven-2.0.9 gewählt haben, so macht es Sinn einen
symbolischen Link zu erzeugen. Dies erleichtert die Arbeit und erspart die
Anpassung von Umgebungsvariablen im Falle eines Upgrades der Version.
/usr/local % cd /usr/local
/usr/local % ln -s apache-maven-2.0.9 maven
/usr/local % export M2_HOME=/usr/local/maven
/usr/local % export PATH=${M2_HOME}/bin:${PATH}

Ist Maven einmal installiert ist, müssen Sie noch ein paar Schritte unternehmen,
damit Maven korrekt funktionieren kann. Zu aller erst sollten Sie das
bin-Verzeichnis Ihrer Maven Distribution (in diesem Beispiel
/usr/local/Apache-Maven/bin) in den Befehlspfad aufnehmen. Ausserdem
sollten Sie noch die Umgebungsvariable M2_HOME auf das
Maven-Top-Level-Verzeichnis setzen (in diesem Beispiel /usr/local/Maven).

Note
Installations-Anweisungen sind die gleichen für OSX Tiger und OSX
Leopard. Es wurde berichtet, dass Maven 2.0.6 mit einer
Vorschau-Version von XCode ausgeliefert wird. Sollten Sie XCode
installiert haben, führen Sie mvn von der Befehlszeile aus, und
überprüfen Sie die Verfügbarkeit. XCode installiert Maven unter
/usr/share/Maven. Wir empfehlen die Installation der jüngsten Version
von Maven 2.0.9, da hier eine Reihe von Bugfixes und Verbesserungen
eingeflossen sind.

Um die Konfiguration beider Umgebungsvariablen bei jedem Start zu setzen, ist es
notwendig diese in einem Skript abzulegen welches bei jedem Systemstart
abgearbeitet wird. Fügen Sie daher die folgenden Zeilen der Datei .bash_login an:
export M2_HOME=/usr/local/maven

17


export PATH=${M2_HOME}/bin:${PATH}

Mit dem Anfügen dieser Zeilen wird Maven Ihrer Umgebung zugefügt, und Sie
bekommen die Möglichkeit Maven von der Kommandozeile zu starten.

Note
Diese Installationsanleitung geht davon aus, dass Sie unter der bash-Shell
arbeiten.

2.3.1.1. Maven Installation unter Mac OSX mit MacPorts
Sollten Sie MacPorts einsetzen, so können Sie Maven installieren, indem Sie die
folgenden Befehle auf der Kommandozeile eingeben:
$ sudo port install maven2
Password: ******
---> Fetching maven2
---> Attempting to fetch apache-maven-2.0.9-bin.tar.bz2 from http://www.apache.org/dist/mav
---> Verifying checksum(s) for maven2
---> Extracting maven2
---> Configuring maven2
---> Building maven2 with target all
---> Staging maven2 into destroot
---> Installing maven2 2.0.9_0
---> Activating maven2 2.0.9_0
---> Cleaning maven2

Für weiterführende Informationen bezüglich der Maven 2 Portierung verweisen
wir auf Portfile. Bezüglich weiterführender Informationen zu MacPorts und wie
dies zu installieren ist: MacPorts Projekt Seite (Engl.).

2.3.2. Maven Installation unter Microsoft Windows
Die Installation von Maven unter Windows ist sehr ähnlich wie jene unter Mac
OSX, die wichtigsten Unterschiede finden sich bezüglich des Installationsortes und
der Festlegung der Umgebungsvariablen. Dieses Buch geht von einem Maven
Installations-Verzeichnis von "C:Program FilesMaven-2.0.9" aus, aber es wird
keinen Unterschied machen, sollten Sie Maven in ein anderes Verzeichnis
installieren, solange Sie die Umgebungsvariablen entsprechend anpassen. Nach

18


dem Entpacken des Maven Installationspaketes müssen Sie zwei
Umgebungsvariablen - PATH und M2_HOME - setzen. Um dies zu bewerkstelligen,
geben Sie auf der Kommandozeile folgende Befehlen ein:
C:Userstobrien > set M2_HOME=c:Program Filesapache-maven-2.0.9
C:Userstobrien > set PATH=%PATH%;%M2_HOME%bin

Das Setzen der Umgebungsvariablen in der Kommando-Zeile erlaubt Ihnen die
Ausführung von Maven während Ihrer aktuellen Sitzung und zwingt Sie diese bei
jedem Neustart erneut zu setzen. Sie sollten diese Variablen daher den
Systemeinstellungen zufügen, öffnen Sie hierzu das Menue "Systemeinstellungen"
von dort "System" und wählen Sie "".

2.3.3. Maven Installation unter Linux
Zur Installation von Maven auf einer Linux-Maschine, folgen Sie der
Vorgehensweise in Abschnitt 2.3.2: "Installation von Maven auf Mac OSX".

2.3.4. Maven Installation unter FreeBSD oder OpenBSD
Zur Installation von Maven auf einem FreeBSD oder OpenBSD Maschine, folgen
Sie der Vorgehensweise in Abschnitt 2.3.2: "Installation von Maven auf Mac
OSX"

2.4. Testen einer Maven Installation
Ist Maven erst einmal installiert, können Sie die Version überprüfen, indem Sie
mvn -v in der Befehlszeile eingeben. Bei einer korrekten Installation von Maven
sollte eine Ausgabe wie folgt erscheinen:
$ mvn -v
Maven 2.0.9

Sollten Sie diese Ausgabe erhalten, wissen Sie dass Maven verfügbar und bereit ist
um eingesetzt zu werden. Wenn nicht, hat Ihr Betriebssystem den mvn Befehl
nicht gefunden. Überprüfen Sie ob die PATH-Umgebungsvariable sowie M2_HOME

19


(Gross/Kleinschreibung beachten!) richtig gesetzt sind.

2.5. Spezielle Installationshinweise
Das herunter zu ladende Maven Paket hat eine Grösse von etwa 1,5 MiB [1], diese
Schlankheit hat es erreicht, da der Kern von Maven mit dem Ziel entwickelt wurde,
Plugins und Abhängigkeiten von einem Remote-Repository dynamisch und auf
Abruf zuzuladen. Wenn Sie Anfangen mit Maven zu arbeiten, lädt Maven zunächst
Plugins in ein lokales Repository. Dieses wird im Abschnitt 2.5.1
"Benutzerdefinierte Konfiguration und -Repository" beschrieben. Im Fall, dass Sie
neugierig sind, lassen Sie uns einen Blick darauf werfen, was sich im Maven
Installationsverzeichnis befindet. 1
/usr/local/maven $ ls -p1
LICENSE.txt
NOTICE.txt
README.txt
bin/
boot/
conf/
lib/

Die Datei LICENSE.txt enthält die Software-Lizenz für Apache Maven. Diese
Lizenz ist in einigen Details in Abschnitt 2.8 "Über die Apache Software Lizenz"
beschrieben. NOTICE.txt enthält einige Hinweise zu Abhängigkeiten von
Bibliotheken, von denen Maven abhängig ist. README.txt enthält
Installationsanweisungen. Das Verzeichnis /bin enthält das "mvn"-Skript, mit
welchem Maven aufgerufen wird. /boot enthält eine JAR-Datei
(classworlds-1.1.jar), welche den Class-Loader unter welchem Maven
ausgeführt wird bereitstellt. /conf enthält eine Datei settings.xml, diese wird
eingesetzt um globale Einstellungen festzulegen um das Verhalten von Maven zu
definieren und anzupassen. Sollten Sie Maven Ihren Gegebenheiten anpassen

1
Haben Sie je eine 200-GB-Festplatte gekauft, nur um herauszufinden, dass diese weniger als 200 GiB
fasst, wenn Sie diese installiert haben? Computer verstehen Gibibytes, aber Einzelhändler verkaufen
Produkte mit Gigabyte. MiB steht für die Mebibyte und ist definiert als 2^20 oder 1024^2. Diese binäre
Präfix Standards sind von der IEEE, CIPM, und und IEC übernommen. Für weitere Informationen über
Kibibytes, Mebibytes, Gibibytes und Tebibytes siehe auch http://en.wikipedia.org/wiki/Mebibyte.

20


müssen, hat es sich herausgebildet, dass man die Einstellungen der settings.xml
durch eine Datei settings.xml im Verzeichnis ~/.m2 übersteuert. /lib enthält
eine einzige JAR-Datei (Maven-2.0.9-uber.jar), welche die
Hauptimplementierung (Core) von Maven enthält.

Note
Mit der Ausnahme einer shared Unix Installation, sollten Sie auf die
Anpassung der settings.xml unter M2_HOME/conf vermeiden. Die
Anpassung der globalen settings.xml-Datei der eigentlichen Maven
Installation ist gewöhnlich unnötig und erschwert den upgrade zwischen
den Maven Installationen unnötigerweise, da Sie daran denken müssen,
die angepasste settings.xml wieder von der bisherigen zur neuen
Maven Installation zurückzukopieren. Sollten Sie dennoch gezwungen
sein, die settings.xml anzupassen, so sollten Sie die 'persönliche'
settings.xml unter ~/.m2/settings.xml anpassen.

2.5.1. Benutzerdefinierte Konfiguration und-Repository
Sobald Sie beginnen sich mit Maven ausgiebig auseinander zu setzen, werden Sie
feststellen, dass Maven einige lokale, benutzerspezifische Konfigurationsdateien
und ein lokales Archiv in Ihrem Home-Verzeichnis angelegt hat. Unter ~/.m2
befinden sich:

~/.m2/settings.xml
Eine Datei mit der benutzerspezifischen Konfiguration der Authentifizierung,
Repositorien und anderen Informationen, um das Verhalten von Maven zu
steuern.

~/.m2/repository/
Dieses Verzeichnis enthält Ihr lokales Maven-Repository. Wenn Sie eine
Abhängigkeit von einem Remote-Maven-Repository herunterladen, so wird
diese in ihrem lokalen Repository zwischengespeichert.

21


Note
Unter Unix (und OSX), bezeichnet die Tilde "~" Ihr Home-Verzeichnis
(d.h. ~/bin bezieht sich auf /home/tobrien/bin). Unter Windows,
werden wir uns ebenfalls mit ~ auf Ihr Home-Verzeichnis beziehen.
Unter Windows XP ist Ihr Home-Verzeichnis C:Dokumente und
Einstellungen<Benutzername>, unter Windows Vista wird Ihr
Home-Verzeichnis mit C:Users<Benutzername> bezeichnet. Im
Folgenden bitten wir Sie entsprechend Ihres Systems den Pfad
anzupassen.

2.5.2. Aktualisieren einer Maven-Installation
So Sie unter Unix/OSX arbeiten und die Installation wie oben unter Abschnitt
2.3.2 "Installation von Maven auf Mac OSX" oder Abschnitt 2.3.3 "Installation
von Maven auf Linux" beschrieben ausgeführt haben, so ist es ein Kinderspiel eine
Maveninstallation zu Aktualisieren: Installieren Sie einfach die neuere Version von
Maven (/usr/local/maven-2.future) neben der bestehenden Version von Maven
(/usr/local/maven-2.0.9). Ändern Sie dann den symbolischen Link
/usr/local/Maven von /usr/local/maven-2.0.9/ auf
/usr/local/maven-2.future. Fertig! Da Ihre M2_HOME Variable bereits auf
/usr/local/Maven zeigt, müssen keine weiteren Anpassungen ausgeführt werden.

Unter Windows, entpacken Sie einfach die neue Version von Maven unter
C:Program FilesMaven-2.future und aktualisieren Sie Ihre M2_HOME Variable
über die Systemsteuerungen.

Note
Sollten Sie die globale Datei settings.xml von /M2_HOME/conf
angepasst haben, so müssen Sie diese Änderungen in das
/conf-Verzeichnis der neuen Installation Übertragen.

22


2.5.3. Upgrade einer Maven-Installation von Maven 1.x
auf Maven 2.x
Beim Upgrade von
<term>Maven 1</term>
auf
<term>Maven 2</term>
werden Sie eine ganz neue POM Struktur sowie ein neues Repository benutzen.
Haben Sie bereits ein benutzerspezifisches Maven 1 Repository für
massgeschneiderte Artefakte erstellt, so können Sie mit Hilfe des Nexus
Repository Manager diese so darstellen, dass sie von Maven 2 Anwendungen
benutzt werden kann. Bezüglich weiterer Informationen zum Nexus Repository
Manager verweisen wir auf Kapitel 16: Repository Manager. Zusätzlich zum
Einsatz von Werkzeugen wie Nexus, können Sie Referenzen auf Repositorien so
einstellen, dass diese das vorgängige Format unterstützen. Bezüglich weiterer
Informationen zum Konfiguration einer Referenz auf ein Maven 1 Repository
siehe auch Abschnitt A.2.8: "Repositorien". Sollten Sie eine Anzahl bestehender
Maven 1 Projekte unterhalten, interessieren Sie sich bestimmt für das Maven One
Plugin. Das Plugin wurde entworfen, um Projekte von Maven 1 auf Maven 2 zu
portieren. Ein bestehendes Maven 1 Projekt können sie portieren in dem Sie das
Goal one:convert wie folgt aufrufen:
$ cd my-project
$ mvn one:convert

one:convert wird eine Maven 1 project.xml Datei einlesen und in eine
pom.xml-Datei konvertieren welches zu Maven 2 kompatibel ist. Sollten Sie
allerdings ein Maven 1 Build Skript mittels Jelly angepasst haben, so müssen Sie
andere Wege gehen. Während Maven 1 Jelly basierte Anpassungen favorisierte, ist
der bevorzugte Weg der Anpassung von Maven 2 Skripten mittels
benutzerdefinierten Plugins, skriptbaren Plugins oder dem Maven Antrun Plugin.
Das Wichtigste was es bei der Migration von Maven 1 auf Maven 2 zu beachten
gilt ist, dass Maven 2 auf einem grundsätzlich verschiedenen Unterbau aufbaut.
Maven 2 setzt auf Lebenszyklusphasen und definiert das Verhältnis zwischen
Plugins auf eine andere Art und Weise. Sollten Sie eine derartige Migration

23


vornehmen, so müssen Sie Zeit einplanen, um sich mit den Unterschieden der zwei
Versionen vertraut machen. Obschon es nahe liegt sich mit der neuen POM
Struktur auseinanderzusetzen, sollten Sie sich zunächst auf das
Lebenszykluskonzept konzentrieren. Sobald Sie das Lebenszykluskonzept
verstanden haben, steht Ihnen nichts mehr im Weg, Maven zur vollen Stärke
einzusetzen.

2.6. Maven De-Installieren
Die meisten Installationsanleitungen für Maven beinhalten das Entpacken des
Maven Bündel in ein Verzeichnis und das Setzen einiger Umgebungsvariablen.
Sollten Sie also Maven von Ihrem Arbeitsplatz entfernen müssen, so müssen Sie
lediglich das Maven Installationsverzeichnis löschen und die Umgebungsvariablen
entfernen. Sie sollten ebenfalls das Verzeichnis ~/.m2 entfernen, da dies Ihr lokales
Repository enthält.

2.7. Hilfe bekommen beim Arbeiten mit Maven
Während dieses Buch das Ziel hat, ein umfassendes Nachschlagewerk zu sein,
wird es Themen geben welche wir verpasst haben oder besondere Umstände und
Situationen sowie Tipps, welche nicht abgedeckt werden. Der Kern von Maven ist
sehr einfach, die eigentliche Arbeit geschieht in den Maven Plugins; und deren gibt
es zu viele um alle in diesem Buch abdecken zu können. Sie werden zwangsläufig
auf Schwierigkeiten stoßen und Eigenheiten finden, welche in diesem Buch nicht
berücksichtigt wurden. In diesen Fällen empfehlen wir Ihnen die Suche nach
Antworten an folgenden Orten:

http://maven.apache.org
Dies sollte der erste Ausgangspunk einer jeden Suche sein. Der Maven-Website
enthält eine Fülle von Informationen und Dokumentation. Jedes offizielle
Plugin hat ein paar Seiten Dokumentation und es gibt eine Reihe von "Quick
Start"-Dokumenten, die zusätzlich zum Inhalt dieses Buches hilfreich sein

24

Maven Definitive Guide De

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Maven Definitive Guide De

Ähnlich wie Maven Definitive Guide De (20)

Maven Definitive Guide De