Ich wollte eigentlich nur etwas ganz simples: Continuous Deployment. Das ist der neueste Trend nach Continous Integration habe ich mir sagen lassen. Und gerade wenn man in einem Team arbeitet ist es schon vorteilhaft, wenn man einen stabilen Build staendig deployt hat.

Hudson ist mein bevorzugter Buildserver (auch wenn Bamboo wirklich ansprechender ist, aber eben auch eine Ecke teurer und nicht OpenSource) – und es gibt auch ein Plugin fuer Hudson, mit dem man ein Deployment anstarten kann: http://wiki.hudson-ci.org/display/HUDSON/Deploy+Plugin
Leider funktioniert das bei dem Glassfish nicht, wenn Hudson nicht auf dem selben Server läuft, wie der Glassfish. (Das sollte/dürfte der Regelfall sein.)

Nachdem der Bug bei Hudson bekannt ist, wollte ich das „mal eben“ beheben. Sollte keine so grosse Sache sein, zumindest für den Hausgebrauch:

  • jelly File anpassen (fuer Eingabe des Hostnamens)
  • Hostnamen verwenden um Cargo zu konfigurieren
  • Plugin bauen und installieren

Leteres war am einfachsten. Hudson ist wirklich kinderleicht für Entwickler zugänglich, sogar wenn man nur ein einzelnes Plugin bauen möchte. Ich habe dazu einfach nur das Deploy Plugin aus dem Subversion bezogen:

svn co https://svn.java.net/svn/hudson~svn/trunk/hudson/plugins/deploy hudson-deploy

und anschließend mittels „mvn clean install“ gebaut. Möchte man nur einmal kurz testen ob alles tut, kann man mittels

mvn org.jvnet.hudson.tools:maven-hpi-plugin:run

Hudson samt dem Plugin in einem Jetty lokal starten. Netbeans (und IntelliJ IDEA) können mit Maven Projekten gut umgehen, so kann man einfach das ausgecheckte Verzeichnis öffnen und direkt loslegen.
Der Plugin-Patch für einen Hostnamen im Hudson Glassfish Deploy Plugin ist relativ kurz und besteht im wesentlichen nur darin den zusätzlichen Konfigurationsparameter abzufragen und an @Property(GeneralPropertySet.HOSTNAME) zu binden.
Dann folgt schnell die Ernüchterung. Es gibt auch bei Codehaus Cargo, der Bibliothek die von dem Deploy Plugin verwendet wird, um das tatsächliche Deployment in einem Container durchzuführen, mehrere Tickets mit Fehlermeldungen, dass kein Remote-Deployment von Codehaus Cargo bei dem Glassfish Applikationserver unterstützt wird.
Hier bekomme ich jetzt die Sorge, dass ich mich auf den Weg mache einen Yak zu scheren.
Codehaus Cargo wird ebenfalls mit Maven gebaut und kann per Subversion ausgecheckt werden:

svn co http://svn.codehaus.org/cargo/trunks cargo-trunk

Das Bauen klappt „nicht so gut“ – die Checkstyle Einstellungen sind so, dass der API Teil nicht baut. („Logmeldungen sollten mit einem Punkt enden“ und dergleichen besonders wichtige Regeln verhindern das.) Pragmatische Abhilfe hilft hier schnell das Testen und Checkstyle auszudrehen:

mvn -DskipTests=true -Dcheckstyle.skip=true install

Schön ist das nicht, aber es handelt sich eben um „trunk“. Der Build bricht auch dann noch ab, aber erst bei dem JBoss Container, und der Glassfish v3 Container für Cargo baut einwandfrei.
Der Code selber… mit spitzen Fingern und ohne das Gefühl wirklich zu wissen, was ich da tue finde ich mehrere Stellen an denen die Strings zum Aufruf von „asadmin“, dem Glassfish CLI Administrationstool zusammengebaut werden.
Ich wollte mich auch nicht tiefergehend mit dem Code beschäftigen, der Patch für Cargo ist relativ einfach gemacht (u.U. nicht vollständig, aber bei mir tat es):

Index: src/main/java/org/codehaus/cargo/container/glassfish/GlassFishInstalledLocalDeployer.java
===================================================================
--- src/main/java/org/codehaus/cargo/container/glassfish/GlassFishInstalledLocalDeployer.java (revision 2596)
+++ src/main/java/org/codehaus/cargo/container/glassfish/GlassFishInstalledLocalDeployer.java (working copy)
@@ -29,6 +29,7 @@
import org.codehaus.cargo.container.deployable.WAR;
import org.codehaus.cargo.container.deployer.DeployerType;
import org.codehaus.cargo.container.glassfish.internal.AbstractGlassFishInstalledLocalContainer;
+import org.codehaus.cargo.container.property.GeneralPropertySet;
import org.codehaus.cargo.container.property.RemotePropertySet;
import org.codehaus.cargo.container.spi.deployer.AbstractLocalDeployer;

@@ -201,6 +202,8 @@
args.add(this.getConfiguration().getPropertyValue(RemotePropertySet.USERNAME));
args.add(„–passwordfile“);
args.add(this.getConfiguration().getPasswordFile().getAbsolutePath());
+ args.add(„–host“);
+ args.add(this.getConfiguration().getPropertyValue(GeneralPropertySet.HOSTNAME));
}

}

Letztes wehwehchen: Da Codehaus Cargo mit Subversion Externals arbeitet, liefert ein „svn diff“ im Rootverzeichnis erstmal keine Ausgabe. Nicht das letzte was an diesem Projekt verwirrend war.
Wer gerne den Erfolg testen möchte, hier ist ein fertig gepatchte Deployer Plugin für Hudson (deploy.hpi). Der Hostname kann unter „advanced“ eingestellt werden. Keine Garantie, Verwendung auf eigene Gefahr. (Wer Lust hat, die Patches bei den jeweilligen Projekten als ersten Vorschlag einzureichen – nur zu!)

Fazit: So macht OpenSource Spass. Nicht zuletzt weil die Projekte entsprechend leicht zugaenglich sind (Subversion, Maven) und weil es gute freie Tools gibt (Maven, Netbeans) mit denen der Einstieg leicht fällt.