Fehlende Einträge

Hier meine unvollständige Liste noch fehlender Einträge. Ich nehme noch gerne Vorschläge für weitere Artikel entgegen.

• Security, Rolls in Tomcat
• Performancevergleich von Webservices im Vergleich zu reinem HTTP
• Optimierter Code
• DB Zugriffe
• XSL
• SCORM
• Automatisierung, Konsistenz

Joel on Software

Es ist schon erstaunlich, dass viele Entwickler ähnliche Probleme haben, zumindest die Guten :-D. Hier ein interessanter Blog: Joel on Software von Joel Spolsky. Joel Spolsky ist ein ehemaliger Fallschirmjäger und Microsoftentwickler. Ob es zwischen diesen Fähigkeiten einen Zusammenhang gibt? In dem Blog geht es um gutes und natürlich schlechtes Projektmanagement aber auch um Programmierdinge (z.B. Blähsoftware, Bytes oder der Joel-Test). Einige Beiträge von 2000 bis 2009 sind auch auf Deutsch verfügbar. Man kann auch bei der Übersetzung helfen. Spontan meine liebste Stelle:

...

Aber ich mache mir nicht über die Tage Sorgen, an denen ich "nur" zwei Stunden arbeite. Es sind die Tage, an denen ich gar nichts tue.

...

Interessant ist auch der Joel-Test, obwohl er schon fast 10 Jahre alt ist, erfüllen immer noch nicht alle Softwarefirmen den Test. Selbst wenn man den Test nicht kennt, so ist sein Inhalt doch für alle guten Programmierer keine Überraschung sondern sollte der Normalfall sein.

Die Forderung des Test eines One-Click-Build passt gut zu Maven und Ant und zu diesem Blog. Ja und ich habe einen zweiten Monitor.

CCD: clean code developer

Viele Dinge in diesem Blog thematisieren die täglichen Probleme. Auch gibt es paar etwas grundlegendere Beiträge nur leider keine grundlegende Verarbeitung dieser Dinge. Ich hatte mir das alles auf einen späteren Zeitpunkt verschoben. Das ist dann wohl zu spät. Aber ich freue mich auf die folgende Webseite hinzuweisen: CCD: clean code developer bzw. auf das Interview.

Ich glaube alle Prinzipien dieser Seite kann ich gutes Gewissens empfehlen, weil ich sie aus meiner Erfahrung selbst anwende und meinen Studenten rate. Die dort beschriebenen Prinzipien lassen sich durch eine Reihe von Werkzeugen sinnvoll unterstützen. Dazu werde ich demnächst einen Beitrag schreiben.

Internationalisierung

Oft stößt man bei Internationalisierung von Java-basierter Software auf das Problem das die Property-Dateien von Java mit einem festen Encoding (ISO-8859-1) eingelesen werden, das man auch nicht ändern kann. Diese Property-Datei dienen zur Aufnahme der lokalisierten Zeichenketten. Wenn es sich nur um gelegentliche Zeichen handelt, die nicht in diesem Encoding vorhanden sind kann man diese Zeichen in UTF-Schreibweise eingeben. Alternatif schreibt man sich eine eigene Klasse die Proppertie-Dateien mit unterschiedlichen Encodings einlesen kann. Dann muss man nur noch eine Methode schreiben mit denen man auf diese lokalisierten String zugreifen kann. Besonders elegant finde ich, folgende Methode String _(String Key) zu definieren und diese dann statisch zu importieren. Noch eleganter wird es wenn man den Key als Fallbackwert zurückgibt wenn der Key nicht vorhanden ist. Natürlich sollt man das in Fehlerlog dann eintragen. Ein wirkliche Alternative zu der Lokalisierung via Property-Dateien ist die Benutzung von XLIFF (XML Localization Interchange File Format).

Vereinheitlichung von GUIs komplexer Applikationen

In vielen komplexeren Projekten hat man das Problem das verschiedene Leute GUI-Teile implementieren. Das führt in vielen Fällen zu einer inkonsistenten GUIs. Dieses Problem kann man auf verschiedenen Wegen angehen. Der Weg 1 wäre einen eigenen Style Guide zu entwickeln und umzusetzen. Dieser Weg erzeugt sehr gute Resultate ist aber aufwendig. Bei der Umsetzung in Java hat man zusätzlich das Problem, dass einige Anforderungen des Style Guides in den Java-Klassen selbst umgesetzt werden müssen andere Dinge hingegen eine Anpassung des Look and Feels (L&F) erfordern.
Der 2. Weg ist pragmatischer und wesentlich einfacher und schneller umzusetzen, dafür sind die Resultate nicht ganz so gut, stellen aber in den meisten Fällen eine wesentlich Verbesserung gegenüber der Ausgangssituation dar. Folgende Regeln sind dafür umzusetzen:

• Verwendung möglichst wenigen Layout Manager z.B. BoxLayout, wenn komplizierter ist und sonst BorderLayout bzw. FlowLayout für Button-Reihen
• Einen Entwickler montiert bzw. überarbeitet der alle Oberflächen
• Convenience Methoden z.B. wenn man Textabschnitte bold setzt
• Minimale und sehr einfache Klassen die alle Entwickler nutzen z.B. für Fenster, dort sind dann Font, Rahmen und Layoutmanager werden schon richtig gesetzt
• Kreuzprüfung der GUI-Teile, d.h. die Entwickler testen die GUI-Teile die von anderen Entwicklern erstellt wurden

Diese Punkte garantieren kein einheitliches L&F der Oberflächen aber sie wirken Wunder und kosten fast nix. Ein weiterer wichtiger Punkt wenn es um das Interface zwischen Maschine und Mensch geht ist die Usability. Aus meiner Sicht ist es wichtig nicht nur in den Evaluationsphase Usability-Tests einzusetzen sondern schon in der Konzeptionsphase. Usability sollte den Entwicklungsprozess begleiten. Hier der Link zur bekanntesten Usability-Web-Seite. ES lohnt sich immer auf dieser Seite zu stöbern.

Noch so ein Programmierer-Blog

Scheinbar gibt es noch ähnlich angelegte Blogs, wie diesen Blog. Schaut mal rein.

Buch zum Logging

Logging ist wenig beachteter Teil von vielen Projekten. Oft wird wenig Zeit in das Logging investiert, weil es kein zentrales Feature der Software ist. Dem entsprechend gut funktioniert es auch. Zur Zeit werden primär drei verschiedene Logging-APIs eingesetzt, log4j, commons-logging und das Logging des JDK (Bestandteil seit dem JDK 1.4). Mein persönlicher Favoriet log4j war aus meiner Sicht lange Zeit nicht allzu gut dokumentiert, vor allem nicht die Möglichkeit der XML-Konfiguration. Aus diesem Grund habe ich mir auch folgendes Buch gekauft. In ihm wird nicht nur log4j erläutert sondern auch das Logging-API des JDK. Aus meiner Sicht könnte es noch weiter in die Tiefe gehen obwohl es schon ein paar Spezialitäten anreisst. Es bietet allgemein ein recht guten Einstieg ins Logging für Programmierer die nicht nur den Logging-Code aus einem alten Projekt kopieren.

Bücherregal

Ich werde hier in loser Folge einige Bücher empfehlen die ich für meine Arbeit nutze. Den Anfang machte gestern ein Buch zu Tomcat.

Tomcat Buch

Dieses Buch ist ein gutes Nachschlagewerk, wenn man mit der Entwicklung von Webapps vertraut ist und Spezialitäten des Apache Tomcat nutzen will. Vor allem für komplexere Web-Projekte jenseits von Spring ist es zu empfehlen als auch für Administratoren. Schon das Vorgängerbuch ist empfehlenswert.

c2in7y8qwm

c2in7y8qwm

Blog: Java ist auch nur eine Insel

Die meisten Programmierer werden das Buch "Java ist auch nur Insel" (Open Book) aus dem Galileo-Verlag kennen und als gutes, schnelles Nachschlagewerk schätzen. Der Autor des Buches, Christian Ullenboom , schreibt nicht nur Bücher, sondern auch noch einen interessanten Blog mit Tipps zum Thema Java.

Develop your developers

Tests ein mal anders. JavaBlackBelt ist ein Community-Website, die Test und Kurse zu vielen aktuellen Themen bietet. Diese stammen primär aus dem Bereich der Java-Programmierung. Je nach dem, wie viele Examen man erfolgreich absolviert hat bekommt man einen entsprechenden, farbigen Gürtel. Der schwarze Gürtel ist dann der höchste zu erreichende Gürtel. Natürlich stellt sich bei einigen Test die Frage, wie relevant sie in der Praxis sind und ob es sich bei dem Code nicht um gefährlichen Code (potentieller Bug) handelt. Trotzdem ist es aus meiner Sicht eine sehr gelungene Site.

Log4J Pattern Layout

Oft hat man beim Logging das Problem, dass ein Logmeldung länger ist als eine Zeil auf dem Bildschirm. Das führt dazu dass diese lange Zeile am Bildschirmrand umgebrochen wird. Für den Programmierer ist dies auf den ersten Blick nicht immer zu sehen, wo die Zeile weitergeht. Für mehr Übersichtlichkeit kann man durch folgendes Pattern sorgen:

< layout class="org.apache.log4j.PatternLayout">
        < param name="ConversionPattern" value="%d [%t] %-5p %c.%M%n: %m%n" />
</layout>

Das ergibt dann folgendes:

2009-07-08 06:59:06,470 [main] INFO  me.alif.App.
App starts up

Bei diesem Pattern wird der Inhalt der Logausgabe, also dass was der Programmierer in die Klammer des Log-Methodenaufruf schreibt, in einer neuen Zeile ausgegeben, die mit einem Doppelpunkt beginnt. Dies führ aus meiner Sicht zu einer höheren Lesbarkeit der Log-Ausgabe.

Tomcat JNDI Realm

Man man Tomcat nicht nur gegen Datenbanken authentifizieren lassen sondern auch gegen andere Naming and Directory Services. Hier ein Beispiel für die Authentifizierung gegen einen LDAP-Server:

<Realm

className="org.apache.catalina.realm.JNDIRealm"

connectionURL="ldap://ldap.rostock.xxx.de"

userPatter="|(cn={0},ou=XXX,o=XX1)(cn={0},ou=XX1,o=XXX)(cn={0},ou=XXX,ou=XY,o=XX1)(cn={0},ou=XX1,ou=XY,o=XY)"

userRoleName="SmartBluUserRole"

roleSearch="(uniqueMember={0})"/>

Jetzt muss man nur noch das formulieren des LDAP-Such-Pattern beherrschen.

Tomcat JDBC Realm

Mit Hilfe des JDBC Realms kann man in Tomcat sehr einfach und elegant eine Benutzerauthentifizierung und Zugriffsteuerung durchführen, bzw. von Tomcat durchführen lassen. Dafür muss man in der Datei context.xml der Webapp folgenden Abschnitt einfügen:

<Realm className="sb.realm.SmartBLURealm" debug="99"

driverName="com.mysql.jdbc.Driver"

connectionURL="jdbc:mysql://localhost:3306/test"

connectionName="smartblu"

connectionPassword=""

userTable="USER"

userNameCol="LoginName"

userCredCol="Password"

userRoleTable="user_roles"

roleNameCol="role_name"

digest="sha"/>

Tomcat versucht dann die Benutzer zu Authentifizieren gegen eine Datenbank jdbc:mysql://localhost:3306/test mit den entsprechenden Parametern. Der Datenbank-Table heisst hier USER. Die Passwörter der Benutzer sind mit SHA gehasht. SHA bedeutet in der Java-Welt meines Wissens nach SHA2.

In diesem Beispiel wir nicht der normale JDBC Realm verwandt sondern ein eigener Realm, der von JDBC Realm abgeleitet wurde aber gleichzeitig ein Migrationsfunktion (das Altsystem verwendete nicht SHA sondern Crypt) besitzt. Die Jar-Datei die die hier verwandte Klasse enthält muss für Tocat verfügbar sein, sie muss sich also im Verzeichnis tomcat/libs befinden. Alternativ kann in dieses Beispiel auch der JDBC Realm (org.apache.catalina.realm.JDBCRealm) eingetragen werden.

Der Realm ist aber nur ein Baustein bei der Authentifizierung mit Tomcat. Die weiterne Bausteine (Login-Config, Rollen und Security Constraints) sind in der Datei web.xml des Projektes enthalten.

Fluent Interface - schlechter Stil hat einen Namen

Gester oder war es Vorgestern bin ich gleich zweimal auf ein Problem gestossen, dass einige Programmierer in einer Codezeile lange, komplexe, häufig ineinander geschachtelte Anweisungen schreiben. In einigen Fällen sieht da sehr elegant aus und es spart Platz, d.h. man muss nicht so viel scrollen im Editor. Diese Art des Code Schreibens hat aus meiner Sicht zwei Mankos, auch wenn ich weniger scrollen muss sinkt die Verständlichkeit des Codes und wenn ein Fehler in dieser Zeile auftritt (Nullpointer in Zeile 137), muss diesen Ausdruck zerlegen um den Bug zu finden. Aus diesem Grund halte ich auch trinäre Ausdrücke für potentielle Fehler.

Daraufhin habe ich in der Newsgroup de.comp.lang.java den Verweis auf die Idee des Fluent Interface gefunden. Die oben beschrieben Art der Programmierung ist kein Fluent Interface. Fluent Interface ist eine elegante Art der Programmierung die vor allem Domain-spezifisch, sehr effizient sein kann. Der Vorteil der Natürlichsprachlichkeit dieser Ausdrücke halte ich nicht unbedingt für einen Vorteil, das mag vielleicht auch mit mit meinen mit Lingo (Macromedia Director, jetzt Adobe Director) gemachten Erfahrungen zusammenhängen. Die Natürlichsprachlichkeit war ja ein Kernfeature von Lingo.

Texte für LaTeX-Dokumente schreiben.

Die aktuellen Office-Pakete glänzen heute durch eine recht gute Rechtschreib- und Grammatikprüfung, ein Feature das vielen LaTeX-Editoren fehlt. Ein Möglichkeit dies zu kompensieren ist die Verwendung von Open Office mit der Erweiterung Writer2LaTeX. Mit ihr kann man Open Office Textdokumente als LaTeX-Dokumente exportieren.

Wo sollen die JUnit-Tests ausgeführt werden?

Wenn man ein Projekt mit Hilfe Mavens realisiert, steht man meist vor der Frage wo man die JUnit-Tests ausführt. Natürlich in Maven, das funktioniert prima auf Grund der meist durch Maven definierten Projektstruktur (ich weiss, sie ist natürlich änderbar). Das Problem was ich dann habe, es dauert länger bis ich weiss wie das Ergebnis der Test ist, dazu kommt das die Integration der Testergebnisse und deren graphische Darstellung (lange List in der Console) im Vergleich zur JUnit-Komponnente aus Eclipse mau ist. Wenn ich versuche einzelne Tests oder alle Tests des Projekts via Run-Menü in Eclipse ausführen zu lassen schlägt dies fehl. Abhilfe schafft dort ein anderer Weg (siehe Bild), wähle im Package Explorer das Projekt aus, gehe dann auf den Menüpunkt Run As und dort weiter auf den Punkt 5 JUnit Test. Das wars, jetzt können alle Tests sowohl in Maven als auch in Eclipse ausgeführt werden.

Projektmanagementfehler

Hier ein Sammlung meiner liebsten Projektmanagement-Fehler:

• Es wird eine neue Software  entwickelt die am Markt verfügbar ist, aber in schlechterer Qualität.
• Projekte mit diversen Unterprojekten werden ohne Koordinator versucht.
• Projekte mit diversen Unterprojekten werden ohne Integrationskonzept und ohne Personalaufwand für die Integration versucht.
  
• Einheitliche Richtlinien für grosse Projekte werden nicht entwickelt oder nicht umgesetzt bzw. es wird die Umsetzung wird nicht überwacht.
• Usability wird als Beiwerk in Projekten betrachtet.
• Projektpläne werden nicht an veränderte Bedingungen angepasst.
• Hippe Techniken werden ohne Rücksicht auf die Bedingungen im Projekt eingesetzt.
• Erkannte Architekturfehler werden ignoriert.
• Komplexe Projekte werden ohne Entwicklungsiterationen versucht.
• Zeitverzug in Projekten wird ignoriert, es wird dann auf auf die Selbstheilungskräfte im Projekt gesetzt.
• Man ignoriert elementare Anforderungen des Kunden um sich selbst zu verwirklichen.
• Man lässt den Kunden alles Bestimmen (zu diesem Thema gibt es übrigen eine Simpsons-Folge in der Homer ein Auto entwirft).
• Gute Projektidee werden durch mangelhafte Benutzeroberflächen sabotiert, weil bei der Planung niemanden Aufgefallen ist, dass die Software durch eine GUI bedient werden soll. Selbst nach dem erkennen dieses Problem werden keine Ressourcen in die GUI investiert unter dem Motto "Wir haben eine Software mit den versprochenen Funktionen umgesetzt.", dass Niemand sie bedienen kann ist nicht unser Problem.
• Schwierigkeiten in Projekten werden nicht konsequent angegangen sondern es wird entweder versucht das Problem zu ignorieren (Probleme die ich nicht sehe sind auch nicht da.) oder es wird herum lamentiert und die sich Sachen schöngeredet und versucht es nicht wie einen Fehler aussehen zu lassen.

Spring

Zur Zeit arbeiten wir an einem Projekt (Server, Fat-Client) in welchem Spring eingesetzt wird. Primär wird dort nur Dependency Injection (DI) verwand. Andere Dinge wie Aspekte, Lokalisierungsunterstützung oder Messageing kamen nicht zum Einsatz. Ein Probleme die dort auftrat waren:

• Hohe Startup-Zeiten des Clients
• Inkonsistentes Logging
• Laufzeit-Spring-Fehler 
  
• Unzureichende Integration von Spring in Eclipse

Die hohen Startup-Zeiten in Kombination mit dem Problem das viele Spring-Fehlermeldungen erst zur Laufzeit auftraten haben aus meiner Sicht die ganze Entwicklung des Projektes behindert. Aus diesen Gründen wäre es besonders sinnvoll gewesen, wenn der Projektcode Test Driven entwickelt worden wäre. So hätte man viele Zeit-fressende Iterationen den Entwicklern erspart. 

Test Driven Development (TDD) Vorlesung - Einführung

Bei iTunes gibt es den etwas weniger bekannten Bereich iTunes U. Dort können Universitäten Podcast oder Videopodcast veröffentlichen. Hier habe ich unter anderem eine Vorlesung von RWTH Aachen zu Thema Test Driven Development  von Prof. Jan Borchers (Link) gefunden. Auch wenn dort Xcode als Entwicklungsumgebung verwandt wird, so ist es doch eine gute Einführung in das Thema für Leute die sich das erste Mal mit dem Thema beschäftigen wollen. Leider enthält diese Vorführung einen sehr entscheidenden Fehler. Es wird hier demonstriert wie man Test schreibt. Was fehlt ist, wie man den Code schreibt. Bei TDD ist das schreiben von Code nicht equivalent zum schreiben von herkömmlichen Code, das hängt mit den kurzen Round-Trip-Zeiten zusammen, d.h. zwischen schreiben eines Test und dem schreiben des dazugehörigen Codes vergeht sehr wenig Zeit, z.B. eine Minute auch wird dort nur beiläufig angerissen, wie Test zu schreiben sind. Dies hat aber aus meiner Erfahrung einen entscheidenden Einfluss auf den späteren Code. Aber solche Dinge könnte man ja schon als Vertiefung des TDD ansehen. Sauberer wäre es schon gewesen, die wichtigen Dinge des TDD gleich am Anfang zu erwähnen:

• Test first
• Kurze Round-Trip-Zeiten
• Boundary Test
• Testen mit falschen Parametern (Fehlerbehandlung)
• Einbeziehung von Code-Überdeckung
• Übergang vom Black-Box-Testen zum White-Box-Testen

Spassvögel bei Sun

Warum heisst die grundlegende Klasse in Java eigentlich Object?

Test Driven Development (TDD)

Letztens wurde ich gefragt, wie ich das Problem löse, schwer testbare Klassen zu testen. Eine Möglichkeit wären natürlich Mock-Objekte, also Objekte die fürs Testen gewisse Funktionen als Dummy bereitstellen ggf. auch Datenbanken mit Testdaten aufbauen. Dies ist zwar etwas aufwendiger als das schreiben reiner Tests aber sonst nicht weiter aufregend. Da diese Antwort scheinbar nicht ausreichte, war meine nächste Antwort, dass das Objektmodell dann wohl fehlerhaft wäre und man dort ansätzen müsste. Diese Antwort war wohl nichts für Verfechter der reinen Objekt-orientierten Analyse und Entwurfs. Es wurde daraufhin auch deutlich, dass das Gegenüber unter Extreme Programming (XP) und TDD wohl nur als eine Technik wie z.B. Hibernate verstanden. XP und TDD sind an dieser Stelle mehr, sie sind ein Wechsel bei der Art und Weise wie Software entwickelt wird. Das heisst natürlich nicht, dass sich XP, TDD und Objekt-orientierte Softwareentwicklung sich ausschliessen. XP und TDD sind die nächste Evolutionsstufe der Softwareentwicklung, der Objekt-orientierten Softwareentwicklung.

Mac OS X, die beste Plattform für Java-Entwickler?

Vor einigen Jahren behauptete Apple, MaxOSX sei die beste Plattform für Java-Entwickler. Das stimmt nur zum teil. Einige Zeit verbaute Apple Intel Core Prozessoren. Diese sind im Gegensatz zu den Intel Core 2 Prozessoren nicht 64 Bit tauglich und leider bietet Apple Java 6 nur für 32 Bit Prozessoren an. Von Sun gibt es leider kein Java für den Mac. Auf meinem noch ganz guten iMac mit einem Core Duo Prozessor kann ich nicht mehr entwickeln. Kurze Hoffnung hatte ich als ich diesen Link fand. Aber der Backport lief bei mir nicht.

Zur Zeit setzt ich deshalb VirtualBox und Windows ein um auf meinem Mac mit Java 6 zu entwickeln. Ob das so gewollt ist?

Übrigen hier noch ein nicht mehr ganz so frischer Link  zu diesem Thema.

Maven Buch

Auf den Seiten der Firma Sonatype gibt es ein frei zugängliches (Creative Commons) Buch zum Thema Maven. Hier der Link zur deutschen Version des Buches. Alternativ kann man sich nach einer Registrierung  hier die PDF-Version des Buches herunterladen. 

Maven Philosophie

Man kann Maven am besten vor dem Hintergrund von anderen Build-Werkzeugen wie Ant oder Make verstehen. Ich habe jahrelang alle meine Projekte mit Ant gemanaget. Dadurch ergab sich eine gewisse Standardisierung der Projekte. Ich verwendete immer die selbe bewährt Dateistruktur, immer die selbe Abfolge von Ant-Tasks. In der Regel kopierte ich dann auch die Ant-Build-Datei und passte sie leicht an. Alle Variablen waren richtig gesetzt. Es kam so zu einer Automatisierung der Softwareentwicklung. An dieser Stelle die Maven-Idee an. Maven geht jetzt noch einen Schritt weiter indem Maven davon ausgeht, dass es ein solches Vorgehen bei vielen Softwareentwicklern gibt und automatisiert den Build-Prozess. Dies geschieht auf folgenden Wegen:

• Einführung eines Standard-Lifecycles für den Build-Prozess
• Standard-Dateistruktur fürs Projekt
• Jar-Management
• Plugin-Managment

Das Hauptproblem aus meiner Sicht für Ant-Benutzer ist, dass sich der Lifecycle und auch die Standard-Dateistruktur sich nicht in einer normalen pom.xml widerspiegeln. In Ant oder auch in Make werden nur Dinge ausgeführt, die der Entwickler explizit in den entsprechenden Dateien definiert. In Maven greift hier die Automation, viele Dinge passieren ohne weiteres zutun des Entwicklers. Das man erstmal verkraften. Dazu kommt, dass man dadurch das man keine entsprechenden Anweisungen in der Steuerungsdatei definieren musste, fehlt dem Maven-Einsteiger der offensichtliche Ansatzpunkt um nach seinen Vorstellung das Projekt zu manipulieren. Ein weiterer Stolperstein für Maven-Anfänger oder Umsteiger ist, das der hohe Automatisierungsgrad sich nicht 1:1 durch das Maven-Eclipse-Plugin m2eclipse wieder findet. Dies kann z.B. zu interessanten Fehlern wie dem folgenden führen. Ich habe in Eclipse eine Javaklasse angelegt und dann mir durch Eclipse die passende Testklasse erzeugen lassen. Diese legt Eclipse automatisch im selben Package und im selben Verzeichnis ab. Das führt zu einem Fehler im Maven-Build-Prozess, weil die Testdateien nicht im selben Verzeichnis wie die Klasse liegen dürfen. Ih habe ein bisschen nach diesem Fehler suchen müssen, weil der Code korrekt war, die Dateien sich alle im Build-Path befanden und die Fehlermeldungen nicht auf das eigentliche Problem hinwiesen. In Nicht-Maven-Projekten existiert tritt dieser Fehler nicht auf.

Texlipse

Zur Zeit erstelle ich ein Liste meiner Programmierwerkzeuge. Heute ist der Abschnitt zu Texlipse fertig geworden. Teclipse ist ein Eclipse-Plugin zur Erstellung von Latex-Dokumenten. Weiters ist hier zu finden: http://sites.google.com/site/mirkoebert/Home/werkzeuge

Mehrere Ant-Schnipsel in Maven

Es ist natürlich möglich mehrere Ant-Schnipsel in Maven zu benutzen. Dazu fügt man dem Ant-Plugin mehrere execution in den executions Tag ein. Wichtig hierbei ist die Verwendung des Id-Tags.

    <executions>
       <execution>
             <id>id1</id>

...

Leider kann man für das Id-Tag keine einfache Schreibweise verwenden wie z.B.:

    <executions>
       <execution id="id1" >
...

Das wäre aus meiner Sicht übersichtlicher und platzsparender. Aber es geht nicht.

Interactive Maven

In Ant ist es möglich zur Ausführungszeit via input Variablenwerte durch den Benutzer setzen zu lassen.

<input message="Please enter project name:"
           addproperty="project"
           defaultvalue="ewindtech"
/>

Wenn ich jetzt versuche diesen Ant-Schnipsel in Maven zu integrieren schlägt dies leider fehl. Auf diese Weise kann Maven nicht interakiv gestaltet werden. Schade.

Neue Maven Version

Seit dem 21.3.2009 ist die Maven Version 2.1.0 verfügbar. Dabei handelt es sich primär um eine Bug-Fix-Version. Aus Performancesicht ist die parallele Auflösung von Artefakten hinzugekommen. Dies sollte in der Regel die Performance steigern. Die komplette Liste ist unter http://maven.apache.org/release-notes.html zu finden.

Integration von Ant in Maven

Oft ensteht der Eindruck, dass man sich für ein Build-Werkzeug entscheiden müsste. Dies ist falsch. Richtig ist, dass sich Ant auch in Maven integrieren lässt und es dafür schon passendes Plugin gibt.

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
  <executions>
  <execution>
         <phase>generate-resources</phase>
     <goals>
          <goal>run</goal>
     </goals>
     <configuration>
   <tasks>
    <echo>Hello World</echo>
    <buildnumber file="src/main/webapp/WEB-INF/build.number"/>
   </tasks>
    </configuration>
  </execution>            
   </executions>
</plugin>

Ant gibt in der Console bei der Ausführung den Satz Hello World aus und edswird die Build-Nummer hochgezählt. Beides sind Ant Core Tasks (siehe Ant Manual).

In der Console sieht das dann wie folgt aus:

...
[INFO] [antrun:run]
[INFO] Executing tasks
     [echo] Hello World
[INFO] Executed tasks
...

Zu beachten ist, dass die Ant-Tasks am Ende der mit ihr assoziierten Phase ausgeführt werden.

Interaktivität mit Ant

Ant kann sehr einfach Benutzereingaben während der Ausführung entgegennehmen. Hier das Beispiel:

<input message="Please enter project name:"
       addproperty="project"
       defaultvalue="ewindtech"
/>

Bei der Ausfürung geht eine Dialogbox auf in der der Benutzer einen Test eingeben kann, dieser wird dann der Variable projekt zugewiesen. Diese Variable wird durch diesen Ausdruck gleichzeitig erzeugt. Der Default-Wert der Variable ist in diesem Beispiel ewindtech. Mit message wird der Text der Dialogbox vorgegeben.

Variablen

Variablen sind sowohl in Ant als auch Maven ein nützliche Sache. In Maven werden sie folgt definiert:

<properties>
    <compileSource>1.5</compileSource>
</properties>

Hier wir eine Variable namens compileSource definiert und mit dem Wert 1.5 versehen. Diese kann denn z.B. im Compiler-Plugin eingesetzt werden:

    <source>${compileSource}</source>

In Ant sieht das ähnlich aus:

<property name="classes" value="WebContent/WEB-INF/classes" />

Hier wurde eine Variable mit dem Namen classes erstellt und ihr der Wert WebContent/WEB-INF/classes zugewiesen. Benutzt werden kann dann die Variable wie folgt:

<target name="prepare" depends="">
    <mkdir dir="${classes}"/>
</target>

Maven Compiler Plugin konfigurieren

Leider wird der Java-Compiler von Maven per default sehr konservativ mit Parametern beschickt. So das es fast immer notwendig ist die Einstellungen anzupassen. Dies passt aus meiner Sicht eigentlich nicht zur Maven-Philosophie.
So muss man die Sprachversion und Encoding des Quelltextes und die Zielsprachversion in fast allen Fällen explizit angeben. Hier ein Beispiel:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
   <source>1.8</source>
   <target>1.8</target>
   <encoding>UTF-8</encoding>
</configuration>
</plugin>

Wichtig ist die korrekte Schreibung der XML-Tags, so sind die i der Ids gross geschrieben.

Maven 2

Wer mit Maven arbeitet, kommt nicht umhin Jar's zu ins eigenen Projekt zu integrieren, die nicht im zentralen Repository zu finden sind. Um solche fremden Pakete (Jar's) in eigene Repository (/Users/ebert/.m2) zu integrieren benötigt man nicht eine eigene Maven-Installation. Klassischer Wiese braucht man eine Maven-Installation und führt dann in der Shell folgenden Befehl aus: mvn install:install-file -DgroupId=java.plugin -DartifactId=plugin -Dversion=jre-1.5 -Dpackaging=jar -Dfile=/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/lib/plugin.jar -- jetzt ist das betreffende Jar registriert.
Wenn man mit Eclipse arbeitet kann man das auch ohne zweite Maven-Installation machen. Eclipse bringt Maven schon mit. So kann man z.B: install:install-file -DgroupId=java.plugin -DartifactId=plugin -Dversion=jre-1.5 -Dpackaging=jar -Dfile=/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home/lib/plugin.jar direkt im Run-Dialog unter Goals von Maven eingeben. Dieser Dialog ist eigentlich nicht für diese Verwendung gedacht, funktioniert aber.

Ant vs. Maven

Die Frage nach den richtigen Build-Tool. Ja gibt es da überhaupt? Ich habe jetzt über viele Jahre mit Ant gearbeitet und damit auch komplexe Projekte gebaut. Einige Highlights: Integration von C++, Deployment zu verschiednen Tomcat-Instancen, automatische Adaptation an Kunden und parallele Ausführung von Build-Teilen. Ich habe ein gutes Verständinis von dem was Ant kann und wie Ant funkioniert. Etwas was immer wiederkehrte war, das ich zwischen den verschiednen build.xml Dateien Code hin und her kopierte und das ich gleichzeitig begann die Projektstruktur und den Build-Prozess zu vereinheitlichen. Dann kam Maven. Die ersten frühen Versuche schlugen fehl. Die Gründe dafür waren die andere Philosophie von Maven (Convention over Configuration), die Intrasparenz was wann passiert und die Integration in Eclipse erschien mir nich so hilfreich. Ich blieb erst mal bei Ant.
Das nächste Erlebnis war auch nicht viel Besser, trotzdem versuchte ich es noch ein mal. Ich migrierte ein größeres Projekt von Ant zu Maven. Ja es funktionierte. Dafür benutzte ich das Eclipse-Plugin m2eclipse. Alles gut? Ja, aber ich hätte da noch ein paar kleine Wünsche:

• Einfachere Integration fremder Jar's in das Projekt
• Einfache Übernahme der Maven-Konfiguration zwischen verschiedenen Rechnern
• Bessere, einfachere Suche nach Jar's (Dependencies)
• Automatische Mirror-Konfiguration
• Verbinden der Konsolenausgaben (Fehler) mit Eclipse
• Automatisches Deployment von War's via Tomcat Manager
  

Mein Fazit, ich werde weiter auf Maven setzen und spezielle Dinge (Projekt-Adaptation) mit Ant erledigen.

Hier noch eine kleine Ant-Referenz: