Dependency Management mit Ant

Genau. Einer der oft genannten Vorteile von Maven im Vergleich zu Ant ist das Dependency Management. D.h. in Maven muss man nur angeben welche Bibliotheken man für das Softwareprojekt braucht und Maven lädt die JARs dann automatisch aus dem Internet und legt sie im lokalen Repository ab. Bei Ant muss man die JARs selber laden und verwalten. Dies ist nicht notwendig wenn Apache Ivy eingesetzt wird. Ivy übernimmt das Dependency Management bei Ant-Projekten. Das schöne an Ivy ist die Kompatibilität zu Maven. Die Beschreibung der Bibliotheken erfolgt nach dem gleichen Prinzip und benutzt auch das zentrale Maven Repository. Aktuell gibt es bei IT Republik einen Artikel zu Ivy.

Brownfield Projekte

Nicht alle Projekte starten auf einer grünen Wiese oft oder meistens beziehen sich Projekte auf vorhandene Software, den so genannten Brownfield Projekten. Wie kann man trotz dieser existierenden und oft laufenden Software die Grundsätze der CCD (Clean Code Developer). Mit diesem Thema beschäftigen sich zwei Artikel auf Heise Developer. Ich denke vielen Entwicklern werden einige Dinge bekannt vorkommen.

Maven vs. Ant

"Maven - eine Ausgeburt der Hölle", das ist ein toller Aufmacher von JAXenter. Das Zitat stammt von Kent Spillner, aus diesem Artikel. Interessant ist, dass Ant zumindest das zweit beste Build-Tool ist. Was sich dahinter versteckt, ist ein tiefer Frust über Maven. Maven sollte das Leben und den Build vereinfachen. Mein Urteil ist noch nicht gefällt. Auf jeden Fall sollt man diesen Blog-Eintrag lesen, oft habe ich mit dem Kopf genickt. Maven bringt aber noch andere Probleme mit sich, die zum Teil aus der Transparenz der Vorgänge in Maven herrühren. Das Dependency-Management ist einer der Argumente für Maven. Mein erstes Problem, wie heisst das Artefakt. Ausserdem lädt das Depency-Management alle möglichen Pakete, egal ob ich sie nötig sind oder nicht. Die Frage ist das ein Problem oder nicht, ich merke davon nichts und ich hab' keinen Einfluss drauf. Doch da fällt mir ein Nachteil ein, wenn ich Web-Applikationen entwickle und deploye muss ich ein grösseres WAR-transferieren, das kostet mehr Zeit und was das für bedeutet, kann man bei Joel Splonsky nachlesen.

Ein Kritikpunk von Kent Spiller, dass das Maven-Paradigma "Convention over Configuration" bei fast jeder Anforderung an den Build-Prozess nicht stimmt kann ich nachvollziehen, vor allem bei grösseren Projekten. Meine Idee ist es Projekte stärker zu modularisieren und jedes einzelne Projekt mit Maven zu realisieren. Vorteile sind überschaubare, wenig modifizierte (konfigurierte) POMs. Am besten man richtet dann auch gleich ein eigenes Remote-Repository ein, wie in diesem Blog beschrieben. D.h. benutze Maven bei grossen, modularen Projekten, sonst nehme lieber Ant.

Aber es ist schon ein Ärgernis, dass man bei Maven so viel konfigurieren muss und dass die Dokumentation spärlich ist. Ein andere Tipp ist, komplexere Anforderungen via Ant zu realisieren.

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).