Der Maven 2 POM entmystifiziert

Ein Projekt aufzubauen ist ein komplexes Geschäft. Aufgrund der Dutzenden von Aufgaben, die zum Konvertieren Ihrer Vielzahl von Dateien in ein Arbeitsprogramm erforderlich sind, gibt es buchstäblich Hunderte von Tools, die alles tun, von der Generierung des Quellcodes über das Kompilieren, Testen, Verteilen bis zum Aufbrühen Ihres Morgenkaffees (falls) Sie finden einen, lieber Leser, lassen Sie es mich wissen. Viele dieser Programme sind hervorragend in dem, was sie tun. Leider gibt es für diejenigen von uns, die große Build-Systeme für ihren Lebensunterhalt verwalten, selten viel Gemeinsamkeiten. Jedes Programm erfordert eine eigene Installation und esoterische Konfiguration. Es ist zu einer unvermeidlichen Tatsache in unserem Leben geworden, dass die meisten Build-Systeme durch manuelles Kleben dieser Tools mit mehreren Homebrew-Skripten (ja, Ant-Skripte zählen) kundenspezifisch erstellt werden.

Maven ist mehr als ein anderes Build-Tool ein Build- Framework . Es trennt Ihren Code sauber von Konfigurationsdateien, Dokumentation und Abhängigkeiten. Maven ist überraschend flexibel darin, Benutzern die Konfiguration der meisten Aspekte ihres Codes sowie die Steuerung des Verhaltens von Plug-Ins, einzelner Ziele und sogar des Build-Lebenszyklus selbst zu ermöglichen. Maven ist die eigentliche Struktur, und innerhalb dieser Mauern wohnt Ihr Projekt. es möchte ein zuvorkommender Gastgeber sein.

Das Problem bleibt jedoch bestehen: Die Verwaltung der Arbeit von Tausenden von benutzerdefinierten Build-Skripten in einem einzigen Framework ist schwierig und erfordert, um richtig ausgeführt zu werden, viele Informationen. Glücklicherweise war das Maven 2-Team ziemlich erfolgreich. Maven 2 lernt aus den Fehlern von Maven 1, unzähligen Benutzeranfragen, Optimierungen und Aktualisierungen und ist leistungsstärker als je zuvor. Leider geht mit großer Leistung eine großartige Konfiguration einher. Damit Maven 2-Artefakte leicht tragbare Einheiten sind, wird diese komplexe Konfiguration in einer einzigen Datei zusammengefasst. Geben Sie den Maven POM ein.

Was ist der POM?

POM steht für Projektobjektmodell. Es ist eine XML-Darstellung eines Maven-Projekts in einer Datei mit dem Namen pom.xml. In Gegenwart von Maven-Leuten spricht das Sprechen von einem Projekt im philosophischen Sinne, jenseits einer bloßen Sammlung von Dateien, die Code enthalten. Ein Projekt enthält Konfigurationsdateien sowie die beteiligten Entwickler und Rollen, das Fehlerverfolgungssystem, die Organisation und Lizenzen, die URL, unter der sich das Projekt befindet, die Abhängigkeiten des Projekts und alle anderen kleinen Elemente, die für die Bereitstellung von Code ins Spiel kommen Leben. Ein Projekt ist eine zentrale Anlaufstelle für alle damit zusammenhängenden Dinge. In der Maven-Welt muss ein Projekt überhaupt keinen Code enthalten, sondern lediglich eine pom.xml. Wir werden später in diesem Artikel auf einige solche Projekte stoßen.

Ein kurzer struktureller Überblick

Das POM ist groß und komplex, so dass das Zerbrechen in Stücke die Verdauung erleichtert. Für die Zwecke dieser Diskussion werden diese Teile in vier logische Einheiten unterteilt, wie in Abbildung 1 dargestellt: POM-Beziehungen, Projektinformationen, Build-Einstellungen und Build-Umgebung. Wir werden zunächst die POM-Beziehungen diskutieren.

Unten finden Sie eine Liste der Elemente direkt unter dem Projektelement des POM. Beachten Sie, dass modelVersionenthält 4.0.0. Dies ist derzeit die einzige unterstützte POM-Version für Maven 2 und wird immer benötigt. Die Maven 4.0.0-XML-Schemadefinition befindet sich unter //maven.apache.org/maven-v4_0_0.xsd. Die Elemente der obersten Ebene lauten wie folgt:

4.0.0

... ... ... ... ... ... ...

... ... ... ... ... ... ... ...

... ... ... ...

... ... ... ...

... ... ... ... ...

POM-Beziehungen

Unsere erste Aufgabe besteht darin, die Projektbeziehungen zu untersuchen, die in Abbildung 2 als obere linke Ecke des Diagramms in Abbildung 1 dargestellt sind.

Projekte müssen in irgendeiner Weise miteinander in Beziehung stehen. Seit der Erstellung der ersten Assembler waren Softwareprojekte abhängig. Maven hat mehr Formen von Beziehungen eingeführt, die bisher in einer solchen Form für Java-Projekte nicht verwendet wurden. Diese Beziehungen sind Maven-Koordinaten, koordinatenbasierte Abhängigkeiten, Projektvererbung und Aggregation.

Koordinaten

Jedes Maven - Projekt enthält eine eigene eindeutige Kennung, genannt die Projektkoordinaten , die wie ein Artefakt Adresse fungiert, ist es einen einzigartigen Platz in der Maven Universum geben. Wenn Projekte keine Beziehung zueinander hätten, wären keine Koordinaten erforderlich. Das heißt, wenn ein Universum nur ein Haus hätte, warum würde es eine Adresse wie 315 Cherrywood Lane benötigen?

Der folgende Code ist der minimale POM, den Maven 2 zulässt - , und sind alle erforderlichen Felder. Sie fungieren als Vektor im Maven-Raum mit den Elementen Zackenbarsch, Kennung und Zeitstempel.

4.0.0org.codehaus.mojoa1

In der Maven-Welt bilden diese drei Hauptelemente (Die Maven-Dreifaltigkeit - siehe, ihre Herrlichkeit!) Die Koordinaten eines POM. Die Koordinaten sind in Abbildung 3 dargestellt.

Vielleicht ist dieser POM an sich nicht so beeindruckend. Es wird besser.

Abhängigkeiten

Einer der mächtigsten Aspekte von Maven ist der Umgang mit Projektabhängigkeiten, und in Maven 2 umfasst dies transitive Abhängigkeiten. Abbildung 4 zeigt, wie wir sie grafisch darstellen werden.

Das Abhängigkeitsmanagement hat eine lange Tradition darin, für alles andere als das trivialste Projekt ein kompliziertes Durcheinander zu sein. "Jarmageddon" entsteht schnell, da der Abhängigkeitsbaum für Architekten, die von neuen Absolventen verachtet werden, die "es total besser hätten machen können", riesig, kompliziert und peinlich wird. Es folgt "Jar Hell", in dem Versionen von Abhängigkeiten von einem System nicht ganz dieselben Versionen sind wie die für die Entwicklung verwendeten. Sie haben entweder die falsche Version oder widersprüchliche Versionen zwischen ähnlich benannten JARs. Daher beginnen die Dinge zu brechen und herauszufinden, warum dies schwierig ist. Maven löst beide Probleme, indem es über ein gemeinsames lokales Repository verfügt, über das Links zu den richtigen Projekten, Versionen und allem erstellt werden können.

Erbe

Eine der Funktionen, die Maven 2 aus den Maven 1-Tagen mit sich bringt, ist die Projektvererbung, wie in Abbildung 5 dargestellt. In Build-Systemen wie Ant kann die Vererbung zwar simuliert werden, aber Maven hat den zusätzlichen Schritt unternommen, um die Projektvererbung explizit zu machen das Projektobjektmodell.

Der folgende Code definiert ein übergeordnetes POM in Maven 2:

4.0.0org.codehaus.mojob2pom

Dieser Elternteil sieht unserem ersten POM ähnlich, mit einem kleinen Unterschied. Beachten Sie, dass wir den packagingTyp als festgelegt haben pom, der sowohl für übergeordnete als auch für Aggregatorprojekte erforderlich ist (mehr dazu packagingim Abschnitt "Build-Einstellungen"). Wenn wir das obige Projekt als übergeordnetes Projekt verwenden möchten, können wir das Projekt- org.codehaus.mojo:aPOM folgendermaßen ändern :

4.0.0org.codehaus.mojob2a

It is important to note that all POMs inherit from a parent whether explicitly defined or not. This base POM is known as the "super POM," and contains values inherited by default. An easy way to look at the default configurations of the super POM is by creating a simple pom.xml with nothing but modelVersion, groupId, artifactId, and version, and running the command mvn help:effective-pom.

Beyond simply setting values to inherit, parents also have the power to create default configurations for their children without actually imposing values upon them. Dependency management is an especially powerful instrument for configuring a set of dependencies through a common location (a POM's parent). The dependencyManagement element syntax is similar to that of the dependency section. What it does, however, is allow children to inherit dependency settings, but not the dependency itself. Adding a dependency with the dependencyManagement element does not actually add the dependency to the POM, nor does it add a dependency to the children; it creates a default configuration for any dependency that a child may choose to add within its own dependency section. Settings by dependencyManagement also apply to the current POM's dependency configuration (although configurations overridden inside the dependency element always take precedence).

Aggregation

A project with modules is known as a multimodule project. Modules are projects that a POM lists, executed as a set. Multimodule projects know of their modules, but the reverse is not necessarily true, as represented in Figure 6.

Assuming that the parent POM resides in the parent directory of where POM for project a lives, and that the project a also resides in a directory of the same name, we may alter the parent POM b to aggregate the child a by adding it as a module:

4.0.0org.codehaus.mojob2poma

Now if we ran mvn compile in the base directory, you would see the build start with:

[INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Unnamed – org.codehaus.mojo:b:pom:2 [INFO] Unnamed – org.codehaus.mojo:a:jar:2 

The Maven lifecycle will now execute up to the lifecycle phase specified in correct order; that is, each artifact is built one at a time, and if one artifact requires another to be built first, it will be.

A note on inheritance vs. aggregation

Inheritance and aggregation create a nice dynamic for controlling builds through a single, high-level POM. You will often see projects that are both parents and multimodules, such as the example above. Their complementariness makes them a natural match. Even the Maven 2 project core runs through a single parent/multimodule POM org.apache.maven:maven, so building a Maven 2 project can be executed by a single command: mvn compile. Although used in conjunction, however, a multimodule and a parent are not one in the same, and should not be confused. A POM project (acting as a parent) may be inherited from, but that parent project does not necessarily aggregate any modules. Conversely, a POM project may aggregate projects that do not inherit from it.

Wenn alle vier Teile der Gleichung zusammengesetzt sind, sehen Sie hoffentlich die Leistung des Maven 2-Beziehungsmechanismus, wie in Abbildung 7 dargestellt.

Maven bietet uns einen guten Rahmen, um Projekte miteinander in Beziehung zu setzen, und durch diese Beziehungen können wir Plug-Ins erstellen, die von jedem Projekt gemäß den Konventionen von Maven wiederverwendet werden können. Die Fähigkeit, Projektbeziehungen zu verwalten, ist jedoch nur ein Teil der gesamten Maven-Gleichung. Der Rest des POM befasst sich nicht mit anderen Projekten, sondern mit seinen Build-Einstellungen, seinen Informationen und seiner Umgebung. Lassen Sie uns zunächst untersuchen, wie ein POM Informationen über das eigentliche Projekt enthält, um zu verstehen, wie Projekte aus dem Weg zueinander in Beziehung stehen.