Im zweiten Teil der Storyline geht es um den allgemeinen Aufbau eines Maven-Projekts. Im grunde genommen ist es recht einfach, solch eines zu definieren. Es sind dafür zwei Schritte nötig, wobei der erste Schritt entscheidend ist.
Möchte man von haus aus mit der Maven-Konvention arbeiten, so bietet es sich an, unter Eclipse zu arbeiten und zusätzlich das Maven-Plugin1 zu nutzen. (Es steht selbstverständlich auch ein gleichnamiges Netbeans-Plugin2 zur Verfügung) Hat man dies in seiner Eclipse-Version integriert hat man die Möglichkeit, gleich ein neues Maven-Projekt anzulegen.
Nun ist es aber so, das über Eclipse hinaus, es Zusatzpakete gibt die zum Beispiel sehr viel Code für einen generieren und diese logischerweise die Java-Konvention verwenden. Hier greift das Sprichwort „Never change a running system” und man muss umdenken. In diesem Fall weisen wir dem jeweiligen Hauptprojekt eine „pom.xml” zu. Genauer gesagt, wir erstellen uns diese Datei. Macht man dies nun in Eclipse, erkennt er dies und der Designer öffnet sich. Persönlich mag ich Designer lieber als sich mit dem Quelltexten rumzuschlagen, aber in diesem Fall sollte man eine Ausnahme machen, die „pom.xml” per Hand beschreiben und später lieber die Anpassungen über den Designer erledigen.
Aufbau einer Standart pom.xml:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.company.projectr</groupId>
<artifactId>com.company.project.application</artifactId>
<packaging>zip</packaging>
<name>Project Name</name>
<version>1.0-SNAPSHOT</version>
</project>
Um den Aufbau etwas einfacher zu halten ist hier kein Doctype definiert. Dieser müßte in der ersten Zeile vollständig lauten:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
Hieraus lässt sich schon eine funktionstüchtige pom-Konfiguration erkennen. Der modelVersion-Tag beschreibt die POM-Version. Zum aktuellen Zeitpunkt wo dieser Beitrag verfasst wurde ist die Version 4.0.0 aktuell. Der groupID-Tag definiert quasi den Projektnamen. Es bietet sich hier an den root-Path zu seinem Projekt zu definieren. Allerdings wäre hier auch ein richtiger Projektname möglich, obwohl sich das in der Praxis dann nicht so gut macht. Wie sich erahnen lässt, beschreibt der artifactId-Tag den Projektnamen. In der RCP-Entwicklung wäre dies, der vollständige Name des Plugins. Der packaging-Tag definiert das Zielformat, wie das Projekt am Ende gepackt wird. Hier wäre es möglich ear, war, jar oder wie in unserem Beispiel das zip-Format anzugeben. Der name-Tag ist sicher selbsterklärend. Dieser beschreibt, wie das Projekt heißt. Zum Schluss gibt es noch ein version-Tag. Wie der Name schon sagt, definiert man hier seine Version. SNAPSHOT bedeutet in diesem Fall, das die Version, sollte sie in einem Repository installiert oder ausgelifert werden, es sich dabei um keine Release-Version handelt und ggf. im laufe der Zeit in seinen Funktionen noch geändert werden kann.