Unexpected content in bundle JAR files

Nun mehr können dadurch produktive Jar-Archive erstellt werden. Dafür ein riesen Dankeschön an Igor Fedorenko!

Das automatisierte generieren von POMs lässt sich nun wieder realisieren. Die neuste Eigenschaft ist, das die groupId nicht mehr automatisch, mit dem übergeordneten Ordner, gesetzt wird, sondern nun explizit mit -DgroupId=… angegeben werden soll. Ich denke dies lässt viel Spielraum für die Strukturierung der Projekte offen. Mir persönlich gefiel ja das automatische setzen besser, aber auch nur weil es gut in mein Konzept gepasst hat.

Eine neue gute Eigenschaft birgt der Inhalt von JAR-Archiven. Hier werden nun durch Maven 3 die unnötigen Daten, wie z.b. die der SVN Dateien, nicht mehr integriert und somit automatisch ausgeklammert. Hierzu gab es in der Vergangenheit das Ticket MNGECLIPSE-1174 auf Sonatype.

Auch bei den Builds hat sich einiges verändert. Sie lassen sich nun auch mit der 0.4.0-DEV realisieren. So gibt man z.B. nicht mehr das Environment in der Befehlszeile an, sondern direkt in der eclipse-application POM.

<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.tycho</groupId>
      <artifactId>maven-osgi-packaging-plugin</artifactId>
      <configuration>
        <environments>
          <environment>
            <os>linux</os>
            <ws>gtk</ws>
            <arch>x86_64</arch>
          </environment>
          <environment>
            <os>win32</os>
            <ws>win32</ws>
            <arch>x86</arch>
          </environment>
        </environments>
      </configuration>
    </plugin>
  </plugins>
</build>

Diese Art und Weise ist natürlich viel einfacher und man muss nun auch nicht mehr für jedes Betriebsystem und Architektur einen separaten Build starten. Nach wie vor sollte man aber darauf achten, dass product - Plugin zu kopieren und die pom.xml wie folgt zu modifizieren:

<!-- groupId welche beim Start von Maven angegeben wird -->
<groupId>some-group-id</groupId>
<!-- Name der product - Datei ohne die extension .product -->
<artifactId>product id</artifactId>
<!-- Version welche in der product - Datei angegeben ist -->
<version>product version</version>
<!-- Definition als Applikation -->
<packaging>eclipse-application</packaging>

Die Angabe eines Environment darf an dieser Stelle auch nicht fehlen (Siehe oben). Da es sonst zu dem Fehler „Product includes native launcher but no target environment was specified” kommt. Hat man die ersten Hürden oder Anpassungen von der 0.3.0-DEV überstanden, lassen sich nun mehr Builds mit dem neuen Pseudo-Release realisieren.

Persönlich würde ich mir noch wünschen das Sonatype mehr Feedback zu den Releases geben würde, damit man genau weiß, worauf man sich einlässt. In Tycho steckt sehr viel potential und ich hoffe in geraumer Zeit wieder ein positives Feedback abgeben zu können.

Die neusten DEVs können unter den Tycho Pseudo-Releases von Sonatype geladen werden. Hier ist es auch möglich auf ältere Builds zurückzugreifen.

[UPDATE]
Seit dem 20.07.09 gibt es nun auch die 0.4.0-DEV-2707. Nach ersten Tests gibt es keine nennenswerten Änderungen. Ebenfalls funktioniert der Build auch mit dieser Version wie gewohnt. Bei einem Build fällt nun auf, das die Zeit für den Build die zuvor leider auch nur 0 angezeigt hat nun gänzlich fehlt.

Bei einem Blick hinter die Kulissen fällt sofort die neue Unterstützung für die MacOS X - Version Cocoa auf. Hier wird nun der Support für die x86- und x64-Architektur bereitgestellt, was einiges wieder sehr einfach machen wird. Experimentell wurde (erst) zum Release die s390-Architektur eingeführt. Dabei handelt es sich um eine weitere Linux-Architektur von IBM. Mittlerweile die zweite die auch von Java unterstützt wird.

Nach einem ersten Start fällt das viel schnellere Laden der Plattform auf. Dies ist einem überabeiteten Backend zu verdanken. Bei einem Update oder Installation eines zusätzlichen Plugins fällt ebenfalls die neue Routine und neuen Views auf. Hier wurde ordentlich optimiert. Dabei wurden die durchzuklickenden Dialoge reduziert. Ebenfalls wird bei der Installation von neuen Plug-ins angezeigt welche Plug-ins noch installiert werden müssen.

Mit Eclipse 3.5 kommen neben den Features für das Auge und der Steuerung auch einige Bugfixes. So ist es nun endlich möglich einen JUnit 4 Provider für Pluginübergreifende Tests einzusetzen. Durch einen Fehler bis zur Version 3.4.2 war dies leider nicht möglich und man musste sich vorerst mit JUnit 3 zufrieden geben. Diese Thematik ist sicherlich sehr interessant für die Reihe an Third-party Programme, die sich im Bereich Continuous Integration tummeln. Eine mitlerweile doch recht bekannte Plattform dafür ist Tycho.

Für umfassende Informationen der Neuerungen in Eclipse, sollte man die Eclipse 3.5 - New and Noteworthy Seite von Eclipse besuchen. Dort wird aufgezeigt an welchen neuen Errungenschaften in den letzten Monaten gearbeitet wurde.

Weiterführende Informationen:

http://www.golem.de/0906/67975.html
http://www.innenspur.de/?p=259
http://javathreads.de/2009/06/eclipse-galileo-veroeffentlicht/

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