Maven Release im Batchbetrieb meistern

1. Setzen der Variable JavaHOME: export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home
2. Einspielen aller Änderungen ins SVN: svn commit -m "test"
3. Das Release vorbereiten: mvn release:prepare  --batch-mode -Darguments='-Dmaven.test.skip=true'
4. Das Release durchführen: mvn release:perform  --batch-mode -Darguments='-Dmaven.test.skip=true'

Mit der Maven Option --batch-mode wird die Interaktivität von Maven abgeschaltet. Dieser Parameter ist z.B. auch im Jenkins oder Hudson hilfreich. Der seltsame Parameter -Darguments='-Dmaven.test.skip=true' führt zu deaktivieren der Tests, in der Regel ist dies nicht notwendig aber zum Testen oft hilfreich. Die Option -Dmaven.test.skip=true ist beim Release nicht wirksam.

Eclipse startet nicht mehr

Auf dem Mac gibt es folgendes Problem: The JVM shared library "/Library/Java/JavaVirtualMachines/openjdk ... " does not contain the JNI-CreateJavaVM symbol.

Scheinbar kollidieren OpenJDK 7 und Oracle JDK. Durch das löschen des OpenJDK kann das Problem gelöst werden:

sudo rm -rf /Library/Java/JavaVirtualMachines/openjdk-1.7-x86_64

Grails Maven Integration

Es gibt verschieden Wege Grails in Maven zu integrieren, z.B. um den Nexus zu benutzen. Da wäre das Grails Plugin Maven Publisher (Link). Dieses ist für Grails 1.X geeignet, wird aber nicht mehr unterstützt. Damit fällt es aus. Ersetzt wurde das Grails Plugin Maven Publisher durch das Release Plugin (Link), welches für Grails 2.X verfügbar ist. Das funktioniert bei aktuellen Grails Projekten, leider wird das Passwort für den Nexus innerhalb des Projektes gespeichert (grails-app/conf/BuildConfig.groovy), das ist überhaupt nicht groovy, das ist fahrlässig. Damit fällt auch diese Lösung aus. Dritter Versuch, erstellen einer POM Datei aus Grails heraus. Das funktioniert nur leider kompiliert dann nichts mehr, unter Java 7 auf dem Mac (siehe Fehlerausgabe unten). Dies ist ein bekannter Bug (Link).

Fazit, drei Möglichkeiten, kein Treffer. Was macht eigentlich Ant?





[ERROR] Unresolveable build extension: Plugin org.grails:grails-maven-plugin:2.1.0 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:1.6 at specified path /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/jre/bundle/Classes/classes.jar @
[ERROR] Unknown packaging: grails-app @ line 8, column 16

at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:339)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:632)
at org.apache.maven.DefaultMaven.getProjectsForMavenReactor(DefaultMaven.java:581)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:233)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
[ERROR]  
[ERROR]   The project com.futuretv.userprofiledatasource:UserProfileDatasource:0.1 (/Users/mirkoebert/Documents/workspace-sts-2.9.0.RELEASE/UserProfileDatasource/pom.xml) has 2 errors
[ERROR]     Unresolveable build extension: Plugin org.grails:grails-maven-plugin:2.1.0 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:1.6 at specified path /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/jre/bundle/Classes/classes.jar -> [Help 2]
org.apache.maven.plugin.PluginResolutionException: Plugin org.grails:grails-maven-plugin:2.1.0 or one of its dependencies could not be resolved: Could not find artifact com.sun:tools:jar:1.6 at specified path /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home/jre/bundle/Classes/classes.jar
at org.apache.maven.plugin.internal.DefaultPluginDependenciesResolver.resolve(DefaultPluginDependenciesResolver.java:215)
at org.apache.maven.project.DefaultProjectBuildingHelper.resolveExtensionArtifacts(DefaultProjectBuildingHelper.java:377)
at org.apache.maven.project.DefaultProjectBuildingHelper.createProjectRealm(DefaultProjectBuildingHelper.java:237)

Jenkins vs Hudson

Wenn um den Einsatz eines Continuous Integration Servers geht, fallen immer zwei Namen: Hudson und Jenkins. Was man oft hört, ist eigentlich das selbe. Ja das stimmt, wenn ich einen neuen Server aufsetze, muss ich vorher für einen von beiden entscheiden. Ich habe von beiden den aktuellen Stand getestet und verglichen. Zum Einsatz kamen Hudson 3.0.0 RC und Jenkins 1.486 auf einem aktuelle Ubuntu. Prinzipiell funktionieren beide Ci Server gleich, die Arbeitsabläuft sind gleich und die Konfigrationsfenster teilweise auch. Der Hudson ist trotz seiner fortgeschrittenen Entwicklung nicht stabil genug, oft funktionieren Dinge nicht (Grails, Ant). Letzlich führten wir die Builds per Shell (grails war) aus. Insgesamt behinderte er die tägliche Arbeit stark. Jenkins dagegen arbeitet wie erwartet. Positiv fiel hier auf, dass man für viele Arbeiten weniger Clicks benötigt. Bezogen auf den aktuellen Entwicklungsstand macht der Jenkins eine deutlich bessere Figur. Es bleibt zu hoffen, das Hudson die Fehler verliert und wieder konkurrenzfähig wird. Zur Zeit fällt meine Empfehlung auf den Jenkins. Übrigens gibt zu beiden CI Servern eine App für iOS. Die Apps werden ich später einem Test unterziehen.

May the test with you...

Objektorientierung: Warum braucht man Getter und Setter.

Es lernt jeder, wenn man objektorientiert Programmiere, greifet man auf die Objekteigenschaften mit Hilfe von get (lesen) und set (schreiben) Methoden zu. Wenn ich mit Java programmiere kann ich mir diese Methoden automatisch erstellen lassen, wenn ich Eclipse nutze. Andere Sprachen (Groovy, PHP) bieten an dieser Stelle ein bisschen Magic an, dort braucht man diese Methoden gar nicht mehr selbst erstellen, sondern sie sind da, das ist noch bequemer. Doch einmal stellt mir ein anderer Entwickler die Frage, wozu brauchen wir Getter und Setter? Ich war sprachlos und dachte eine Weile darüber nach. Die Antwort ist, in der Regel braucht man sie nicht, weil sie keinerlei Logik enthalten. Viele Datenklassen (Domain Objekte) sind reine Datenkontainer, wozu brauch ich da noch Getter und Setter? Sie haben keinen Nutzen, sie sind überflüssig. Sie nur zu implementieren um einer Vorschrift zu genügen ist Unsinn. Ich habe jetzt aufmerksam in meinen Code geschaut und ich hatte einige wenige Getter und Setter. Sie enthielten irgend welche Logik, sonst waren meine Klassen durch den Konstruktor konfiguriert oder die Klasse war Zustandslos, als ein mehr ein Service. Fazit, ich brauche keine leeren Getter und Setter, sie bieten keinen Mehrwert, sie sind überflüssig und nutzlos. Ich werde sie auch nicht vermissen.

Nexus

Der Nexus ist ein Repostory für Java Bibliotheken und Artefakte. Es integriert sich perfekt in Maven. Es gibt neben der freien Version noch ein Professional Version. Ein Vorteil der Professional Version ist, dass man Maven Sites, also Projekt Sites und Reports die durch Maven erzeugt wurden, dort deployen kann. Zur Installation gibt es hier eine Anleitung. Wenn das TGZ zur Installation gewählt wurde ist dringend zu prüfen, ob der Eigentümer und die Gruppe richtig gesetzt sind (root). Dann noch schnell den Benutzer im File /etc/init.d/nexus auf root setzen. Schon läuft der Nexus unter: http://localhost:8081/nexus Benutzername: admin Passwort admin123 (bitte ändern). Jetzt einen Benutzer anlegen und ihm ausreichend Rechte geben. Dann noch Maven konfigurieren, folgende Einträge müssen ins POM:

<distributionManagement> 
    <snapshotRepository> 
        <id>snapshots</id> 
        <url>http://stage02:8081/nexus/content/repositories/snapshots</url> 
    </snapshotRepository> 
    <repository> 
        <id>release</id> 
        <url>http://stage02:8081/nexus/content/repositories/releases/</url> 
    </repository> 
</distributionManagement>

Danach muss noch die user.xml ergänzt werden:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 
                      http://maven.apache.org/xsd/settings-1.0.0.xsd"> 
  <localRepository/> 
  <interactiveMode/> 
  <usePluginRegistry/> 
  <offline/> 
  <pluginGroups/> 
      <servers> 
            <id>release</id> 
            <username>ebm</username> 
            <password>XXX</password> 
        </server> 
        <server> 
            <id>snapshots</id> 
            <username>ebm</username> 
            <password>XXX</password> 
        </server> 
    </servers> 
  <mirrors/> 
  <proxies/> 
  <profiles/> 
  <activeProfiles/> 
</settings>

Jetzt kann man alles testen: mvn deploy

Code Coverage mit Emma

Für die Berechnung der Testabdeckung des Codes gibt es eine Reihe von Werkzeugen, populär sind Cobertura als auch EclEmma. Cobertura wir gerne in Grails verwandt nur leider liefert Cobertura in Verbindung mit Java 7 keine Ergebnisse mehr. Also auf zu Emma. Emma lässt sich sehr einfach als Eclipse Plugin einsetzen, um Emma auch in Maven 3 nutzen zu können bedarf ein wenig Konfiguration.

    <build> 
        <plugins> 
            <plugin> 
                <artifactId>maven-compiler-plugin</artifactId> 
                <version>2.3.2</version> 
                <configuration> 
                    <source>1.7</source> 
                    <target>1.7</target> 
                </configuration>
            </plugin> 


            <plugin> 
                <groupId>org.jacoco</groupId> 
                <artifactId>jacoco-maven-plugin</artifactId> 
                <version>0.6.0.201210061924</version> 
                <executions> 
                    <execution> 
                        <goals> 
                            <goal>prepare-agent</goal> 
                        </goals> 
                    </execution> 
                    <execution> 
                        <id>report</id> 
                        <phase>prepare-package</phase> 
                        <goals> 
                            <goal>report</goal> 
                        </goals> 
                    </execution> 
                </executions> 
            </plugin>

EclEmma basiert auf der Bibliothek jacococ, dem entsprechend muss das Maven Plugin JACOCO benutzt werden. Mit dieser Maven Konfiguration erzeugt man dann zu Eclipse equivalente Reports.

Indikatoren fürs Refactoring

Refactoring ist in der Agilen Welt ein immer währender, fortlaufender Vorgang. Trotzdem gibt es in vielen Projekten Phasen des Refactorings. Woran erkennt man, das Refactoring dringend angeraten wird:

• Zu viele globale Variablen
• Der Programmierer sagt: "Die Methode kann ich nicht testen."
• Das Projekt verwendet veraltete Bibliotheken oder Plugins
• Hidden Features, niemand weiss von diesem Feature
• Nicht benutzte Features
• Es gibt Integrationstest an Stelle von Unit-Tests
• Vererbung und Abstrakte Klassen (in den meisten Anwendungsfällen)
• Verstoss gegen Clean Code wie:
• Code Duplikate, Verstoß gegen die DRY Regel
• Case Anweisungen mit den Werten 1, 2, 3 ... (Java)
• Eval Anweisungen in JS
• Methoden mit Boolean Parametern
• Zu lange Klassen oder Methoden
• Methoden mit drei oder mehr Parametern
• Methoden mit Parametern die als Ausgabe die dienen

Die Liste ist nicht vollständig, bitte gebt mir Feedback zur Erweiterung der Liste.

Maven Basiskonfiguration

Mit Maven 3 hat sich einiges in den Default-Werten geändert. Trotzdem muss man das JDK und das Encoding explizit in der POM Datei angeben:

... 
        <properties> 
        <jdk.version>1.7</jdk.version> 
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> 
        </properties> 
    <organization> 
... 

</project>

So sehen dann die Einstellung zum JDK und zum Encoding in Eclipse aus.

Auch ja, und im PMD Plugin sollten auch die richtige JDK Version gesetzt sein:

... 
                         </plugin> 
                            <plugin> 
                                <groupId>org.apache.maven.plugins</groupId> 
                                <artifactId>maven-pmd-plugin</artifactId> 
                                <version>2.5</version> 
                                <configuration> 
                                    <linkXref>true</linkXref> 
                                    <minimumTokens>100</minimumTokens>
                                    <minimumPriority>5</minimumPriority> 
                                    <targetJdk>1.7</targetJdk> 
                                </configuration>
                            </plugin> 
                    </reportPlugins>
                </configuration>
            </plugin> 
        </plugins> 
    </build> 

Java 7 konfigurieren unter Mac OS X und Eclipse

Java 7 ist endlich für Mac OS X fertig geworden.

• JRE: http://www.oracle.com/technetwork/java/javase/downloads/jre7-downloads-1637588.html
• JDK: http://www.oracle.com/technetwork/java/javase/downloads/jdk7u7-downloads-1836413.html

Aber wie konfiguriert man Eclipse bzw. STS, dass es das neue Java 7 verwendet. Dazu muss man zuerst das neue Java finden (/Library/Java/JavaVirtualMachines/jdk1.7.0_07.jdk/Contents/Home/). Leider kann man diesen Ordner nicht im Eclipse Filechooser auswählen, man muss den Pfad direkt in die Zeile JRE home rein kopieren (siehe Bild unten).

Jetzt muss nur noch ein guter JRE name gesetzt werden. Leider funktioniert dieser Trick bei Open Office nicht.

Damit Maven auch das neue Java 7 benutzt muss die Variable Java_Home gesetzt werden. Am besten editiert man dazu die ~/.profile. Dort fügt man folgende Zeile ein:
export JAVA_HOME="/Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home"

Dann benutzt Maven auch das aktuelle Java:

mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /usr/share/maven
Java version: 1.7.0_11, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk/Contents/Home/jre
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "10.8.3", arch: "x86_64", family: "mac"

Hudson 3 Home

Wer nach dem Home Verzeichnis von Hudson 3 sucht muss eine Weile Suchen. Unter Ubuntu mit einem Tomcat, der aus dem Repository installiert wurde liegt das Home Verzeichnis von Hudson 3 unter: /usr/share/tomcat7/.hudson

Hudson 3 M3

Nach den Aufräumarbeiten der letzten Releases ist jetzt der Hudson 3 Milestone 3 erschienen. Beim Start des Hudson wird man jetzt von einem Login begrüßt. Leider funktioniert der nicht mit den alten Hudson 3 M2 Daten. Das Disablen der Sicherheitseinstellungen true
ändert nichts daran. Also lösche ich die Daten im HUDSON_HOME. Jetzt geht. Übrigens ist mein HUDSON_HOME zu finden unter: /usr/share/tomcat7/.hudson/

Mehr Informationen:
http://hudsoncentral.wordpress.com/2012/06/19/duck-here-comes-m3/

XSL CDATA Hack

Eigentlich habe ich XSL schon lange für tot gehalten wegen der schlechten Wartbarkeit und Toolunterstützung. Doch ich probierte mich mal wieder und war erstaunt, wie gut es ging, bis ich auf folgenden Problem stiess: kopieren eines Textknotens von einer XML Datei in eine andere XML Datei, das ist einfach: xsl:copy-of die HTML Formatierungen blieben erhalten, sehr schön. Leider hat das Importprogramm (OpenCMS), welches die neue XML verarbeiten soll ein Problem mit HTML Tags, es möchte dringend alles durch CDATA umschlossen haben, auch das ist einfach: <xsl:output method="xml" indent="yes" cdata-section-elements="content"/>. Jetzt die beiden Sachen kombinieren, fertig. Doch das funktioniert nicht! Bug oder Feature? Das kann ich schwer entscheiden. Da hilft ein alten HTML/JS Hack weiter. Das CDATA wird in Teilstrichs, hier zerlegt xsl:variable und danach zusammengesetzt. Das ganze sieht dann so aus:

Auf diese Weise kann man XSL COPY-OF mit CDATA kombinieren. Auf das CDATA-SECTION-Element kann verzichtet werden.

Testen mit Grails

Grails ist ein nettes Web Framework. Leider ist das Testen und das Test Driven Development nicht mehr ganz so einfach wie bei der blanken Java Entwicklung. zum Testen in Grails muss man definieren, dass es sich um ein Objekt handelt, dass im Test benötigt wird. Dies geschieht mit Hilfe von mockDomain. Dadurch wird der Grails Kontext dieses Objekts für den Test bereitgestellt. Methoden wie save funktionieren dann. Der zweite Haken ist das Mocken von Services. Mann kann einen z.B. abhängigen Service durch die entsprechende Mock Variante ersetzen, mockFor und createMock sind hierfür notwendig.
Weil diese Beschreibung nicht vollständig ist, hier ein Link auf eine gute Beschreibung:
http://www.ibm.com/developerworks/java/library/j-grails10209/

Polyglote Programmierung

Als ich die Überschrift das erste Mal las, dachte ich zuerst es geht um Internationalisierung und UTF-8, aber nein das Thema polyglotte Programmierung ist spannender. Vereinfacht beschreibt polyglotte Programmierung einen Mix aus unterschiedlichen Programmiersprachen zur Lösung von Softwareentwicklungsaufgaben und bildet damit einen einen Gegenpol zu der vor allem Im Java-Bereich dominieren Auffassung, das eine Programmiersprache für alle Probleme (Server, Smartcard, Client, Real Time) reicht. Oder um es sehr plakativ austzzudrücken: Java und C gegen XML und DSL (domain-specific language). Auf der Heise-Seite gibt es eine kritischen kurzen Artikel zur polyglotten Programmierung (http://www.heise.de/developer/artikel/Warum-Polyglot-Programming-nicht-praxistauglich-ist-1479542.html) bzw. ist das Original auf Englisch als Blog Post erschienen (http://lofidewanto.blogspot.de/2011/10/why-is-polyglot-programming-or-do-it.html). Auch wenn ich offen gegenüber neuen Entwicklungen bin, so kenne ich die Konfigurationshöllen ala Spring und Maven. Auch wenn sich heute der Zustand in der Spring Welt verbessert hat, so bestärkt mich der Artikel in meiner Skepsis gegenüber polyglotten Projekten. Ein Problem der polyglotten Entwicklung muss aus meiner Sicht stärker betont werden, das Problem der Wartbarkeit polyglotter Projekte. Ich bin der Meinung, dass polyglotte Projekt entgegen der eigentlichen Ziele der polyglotten Programmierung zu einer höheren Komplexität neigen. Und die Nachteile, mehr Fehler und hohe Änderungsträgheit überwiegen. Aus meiner Sicht sind gut designte Objekte und Pakete nichts weiter als eine Vorform einer DSL. Wichtig ist, die Benennung und die Sichtbarkeit von Objekten und Methoden so einzusetzen, dass man mit ihnen so effektiv umgehen kann, wie man man es von einer DSL erwarten würde.

Buchreview: Arbeiten statt Deligieren

Junge, neue Unternehmen haben es in Deutschland schwer auf die Beine zu kommen und erfolgreich zu werden. Die bürokratischen Bestimmungen und die Organisations-Mentalität der Deutschen hämt viele gute Ideen und lässt diese schon im Keim ersticken. Das Besteller Buch "Rework" der erfolgreichen Software Schmiede "37signals" aus Amerika beschreibt wie es mit einfachen, greifbaren Mitteln möglich ist gute Ideen auf den Markt zu bringen. Es geht nicht darum teure Werbung zu schalten, Manager einzustellen welche die Arbeit deligieren, lange Meetings zu halten, bis spät in die Nacht zu arbeiten oder Geld von Investoren zu akquirieren. Im Gegenteil, es geht darum Produkte zu entwickeln die einen begeistern, seinen Kunden zuzuhören, ehrlich zu sein und am Erfolg zu arbeiten und das mit Mitteln die wir alle zur Verfügung haben. Die Autoren zeigen wie jeder mit dem Fokus auf das Wesentliche zum Ziel kommt. Diese Maxime wird wunderbar im Buch umgesetzt. Die Kapitel sind nicht länger als zwei Seiten, sind leicht zu lesen und für jeden verständlich. Ein großartiges Buch für Alle die arbeiten und Arbeit produzieren.
REWORK - Jason Fried & David Heinemeier Hansson - Founders of 37signals
Autor des Gastbeitrags: Stefan Laabs

Zeitbetrug aufdecken

Neben den Werksverträgen werden oft Serviceverträge zwischen Unternehmen abgeschlossen. Serviveverträge sind im IT Bereich sehr beliebt. Dazu werde in der Regel die Arbeitszeiten des Dienstleiters nachgewiesen. Praktisch sind im IT Bereich Issue Tracking Systeme wie JIRA dafür. Sie ermöglichen das Festhalten und Dokumentieren der Aufgabe, der Problemlösung und der dafür benötigten Zeiten, sehr praktisch. Sehr praktisch, vor allem weil der Kunde keine Kontrollmöglichkeit Besitz und er dem Dienstleister ausgeliefert ist.

Aber nein, es gibt einfache Möglichkeiten mit Hilfe von ein wenig einfacher Mathematik den Betrugs mit Servicezeiten aufzudecken. Dazu zuerst der Normalfall an einem Beispiel kurz dargestellt, ein Aufgabe kommt herein, und wird auf X h geschätzt und bearbeitet, innerhalb des Bearbeitungszeitraums wird die Zeit für das Bearbeiten verbraucht. Die Aufgabe wird gelöst. In der Regel werden diese Arbeiten beim Kunden zum Monatsende abgerechnet. 

Die allermeisten Abweichungen sind Betrug, die wohl beliebteste Methode ist, wenn der Dienstleister merkt, dass er zu wenig Aufwände (Zeiten) im Monat hatte. Er trägt zum Monatsende, kurz vor Rechnungsstellung gehäuft Zeiten nach. D.h. es werden Zeiten auf längst bearbeitete Vorgänge geschrieben. Um diese Betrugsvariante aufzudecken, muss man nur die Daten, wann Zeiten eintragen wurde in Bezug zum Abrechnungszeitraum setzen. Es kommt zu einer klaren, nicht normalen Häufung. Die zweite Auffälligkeit dieser Betrugsmethode ist die große Differenz (Tage) zwischen dem Datum wann die Zeiten eingetragen wurden und wann sie angeblich angefallen sind. Mit beiden Methoden lässt sich diese Betrugsart erkennen.

Hudson 3 als Alpha Version verfügbar

Tote leben länger, wohl auch im Bereich Continuous Integration. Nachdem auf deutschen Wikipedia Hudson nicht mehr existent war und Hudson nur als Vorgänger von Jenkins am Rande erwähnt wurde, freue ich mich auf den Hudson 3, jetzt unter dem Dach von Eclipse. Ein erster Test (OpenJDK 7, Tomcat 7, Hudson 3.0.0 M0 als WAR), was ist mit meinen Augen, die Farbe, Lila? na gut, also weiter im Test. Einige unangenehme Fehler sind im neuen Hudson nicht mehr drin, so funktioniert jetzt das Deployen auf den Tomcat 7. Der Bug war in der zweier Version seit langem bekannt aber nicht gefixt. Mein normaler Hudson-Job läuft auch ein bisschen schneller, ca. 10 %. Schon die Hudson Alpha Version 3.0.0 M0 ist ein deutlicher Fortschritt und für den Praxiseinsatz tauglich. Auf jeden Fall ist Hudson damit wieder im Rennen, ich werde wohl die deutsche Wikipedia Seite für Hudson anlegen.

http://www.eclipse.org/hudson/download.php
http://hudson-ci.org/

Update:
Geschaft, jetzt gibt es eine neue Seite bei Wikipedia zum Hudson.