Zu erst sollte man sich in Eclipse eine RCP-Anwendung¹ generien lassen oder selbst eins erstellen. Da wir später auch die Product-Konfiguration brauchen, wäre es angebracht, sich diese auch gleich bauen zu lassen und nötige Einstellungen zu treffen. Ich habe soweit alles beim Standard belassen und die Product-Datei „com.company.project.product” genannt. Wenn man die nötigen Konfigurationen für das Produkt getroffen hat lässt sich diese bereits in Eclipse über „Overview -> Launch an Eclipse application” ausführen.

Ich möchte an dieser Stelle nicht tiefer in der RCP-Entwicklung eingehen da dies ein Thema für sich ist. Wer allerdings damit nicht so zurecht kommt, sollte sich noch etwas in die RCP-Entwicklung² einlesen.

Nun erstellen wir uns eine pom.xml mit folgendem Inhalt:

<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">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company.project</groupId>
  <artifactId>com.company.project</artifactId>
  <packaging>zip</packaging>
  <name>Project Name</name></code><code>
  <version>1.0-SNAPSHOT</version>
  ...
</project>

Unsere Anwendung heißt hier: com.company.project. Das Haupt-Plugin analog genauso: com.company.project. Es gilt nun den Inhalt ab Zeile 8 zu füllen. Da wir einen Buildprozess für eine RCP-Anwendung erstellen wollen schauen wir uns zu erst auf der Seite http://mojo.codehaus.org/pde-maven-plugin/index.html um. Dies kommt dem am nächsten was wir machen wollen. Unter Usage haben wir eine wunderbare Beschreibung wie der Konstrukt auszusehen hat:

<project>
  ...
  <packaging>zip</packaging>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>pde-maven-plugin</artifactId>
        <extensions>true</extensions>
        <configuration>
          <buildProperties>
          <!-- Additional PDE ant properies goes here -->
          ...
          </buildProperties>
        </configuration>
        <!-- Also bind to mvn clean -->
        <executions>
          <execution>
            <id>clean-pde</id>
            <phase>clean</phase>
            <goals>
              <goal>clean</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  ...
</project>

Ab nun an wird es etwas knifflig. Man sollte die PDE-Version explizit angeben. Aktuell ist die Version: „1.0-SNAPSHOT”. Dies muss im besten fall unter extensions als version - Tag hinzugefügt werden. Nicht benötigte Inhalte, speziell die Kommentare haben in solch einer Konfiguration natürlich nichts verloren. Also ebenfalls raus damit. Sind diese Dinge abgearbeitet kann sich diese pom-Konfiguration schon sehen lassen. Damit ist zumindest der Grundstein gelegt. Im nächsten Teil der Storyline werden wir uns mit dem Product-Build beschäftigen und unsere erstellte Mail-Application automatisch erstellen lassen.

Weiterführend ist zu sagen, das mit dem PDE-Maven-Plugin sich nicht nur Product, sondern auch Plugins, Features und auch Updatesite automatisch builden lassen. Allerdings ist jeder dieser Bereiche ein Thema für sich und sollten trotz der einfachen Handhabung nicht unterschätzt werden. Persönlich schätze ich den Product-Build als schwierigsten ein.

1. Optional das HelloWorld-Mail RCP
2. http://wiki.eclipse.org/index.php/Rich_Client_Platform

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-Plugin¹ zu nutzen. (Es steht selbstverständlich auch ein gleichnamiges Netbeans-Plugin² 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.

1. http://m2eclipse.codehaus.org/
2. http://maven.apache.org/netbeans-module.html

Wer seinen Buildprozess² automatisieren möchte sollte sich damit vertraut machen. So ein Maven-Projekt bringt von haus aus eine eigene Konventionen mit sich die man nach Möglichkeit auch nutzen sollte. Aber auch für Projekte die Technisch an eine bestimmte Struktur gebunden sind, gibt es Lösungsansätze. Eines sollte man über Maven wissen und sich auch immer im klaren sein, es gibt keinen Standard. Wie ein Build Lifecycle aussehen sollte, richtet sich immer nach den Projekt(en).

Maven bietet aber ein Standard Buildprozess aus folgenden Plugin an:

1. clean (Säubern)
2. validate (Validieren)
3. compile (Kompilieren)
4. test (Testen)
5. package (Verpacken)
6. integration-test (Integrations-Tests)
7. verify (Gültigkeitsprüfung)
8. install (Installieren im lokalen Repository)
9. deploy (Installieren im entfernten Repository)
10. site (Generierung der Dokumentation)

Jede Phase stellt ein Plugin dar und übernimmt verschiedene Aufgaben und definiert letztendlich den Buildprozess. Im folgenden die einzelnen Schritte im Detail:

1. Entfernt Artefakte³ von vorherigen Builds
2. Validiert⁴ das Projekt auf Korrektheit und prüft ob alle Abhängigkeiten⁵ gegeben sind
3. Kompiliert den Programmcode
4. Testet den kompilierten Programmcode mit Hilfe eines unit-testing-framework⁶. Diese Tests sollten nicht verlangen, dass der Code gepackt (packaged) oder ausgeliefert (deployed) sein muss.
5. Fasst den kompilierten Code in einem bestimmten Format zusammen, z.b. zu einer jar.
6. Integrationstests auf anderen Systemen. Es wird dabei getestet ob das Projekt auf dem Zielsystem funktionstüchtig ist.
7. Hier können sonstige Tests angestoßen werden die prüfen ob das Projekt gültig und ggf. bestimmte Qualitätskriterien erfüllt sind.
8. Installiert das Package in das lokale Repository⁷, worauf lokale Projekte in Abhängigkeit dies nutzen können.
9. Installiert das Package in ein entferntes Repository. Dies wird verwendet um stabile Versionen anderen Programmierern zu verfügung zu stellen.
10. Erstellt eine Projekt-Dokumentation. Ebenfalls ist es hier möglich JavaDocs oder Code-Duplicates anzeigen zu lassen.

Es ist für den Anfang sicher etwas viel. Wenn man sich aber etwas eingelesen hat und langsam dahinter steigt, lässt sich daraus eine Menge machen. Und darum geht es in dieser Storyline, einen automatischen Buildprozess aufzubauen.

1. http://maven.apache.org/
2. http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
3. Artefakte sind beispielsweise jar- oder zip-Pakete die durch das kompilieren erstellt werden können. Diese sind zu meist mit einer Versionierung versehen. Diese Artefakte können von anderen Projekten in Abhängigkeit genutzt und eingesetzt werden.
4. Damit prüft das Plugin durch ob im Programmcode Fehler enthaten sind. Das beste Beispiel dafür sind Errors.
5. Projekte greifen i.d.R. auf andere Resourcen zu und damit wird geprüft ob diese vorhanden sind.
6. Ein bekanntes Framework ist JUnit: http://www.junit.org/
7. Stellt ein Verzeichnis da, wo sämtliche Maven und hauseigenen Projekte verwaltet und genutzt werden können