Links der Woche

Das Internet war diese Woche wieder voll. Hier mein Merkzettel:

Java | Template | Thymeleaft

TemplateEngine für Java: Thymeleaft. Die Alternative für das alte Velocity? Mit dem Eclipse-Plugin für Velocity habe ich so meine Probleme. In den aktuellen Eclipse Versionen (z.B. Luna oder das STS von Springsource) habe ich es nicht zum Fliegen bekommen. Was mir besonders gut gefällt, ist die eingebaute Vorschaufunktion von Thymeleaft. Hier ein Beispiel:

<p th:text="#{msg.welcome}">Welcome everyone!</p>

Die Anweisung th:text enfernt den Body aus dem Tag und ersetzt diesen durch das Ergebnis des Ausdrucks msg.welcome. D.h. der HTML Entwickler kann Pseudodaten im HTML Dokument hinterlegen. Die Ersetzungsanweisungen finden sich in den frei definierten Attributen der HTML Elemente wieder. Großer Vorteil: Das HTML Dokument kann jederzeit im Browser betrachtet werden.

Javascript | Seitenübergänge

Javascript, Seitenübergänge oder -fluß nett dargestellt: SmoothState

Javascript | Tabellen in Bootstrap

Javascript, Tabellen für Bootstrap: Bootgrid

Javascript | Swipe Gesten

Javascript, Swipe-Gesten: Brutaldesign

Javascript | Graphics

Javascript Bibliothek für das Zeichnen von Diagrammen (Punktdiagramm, Linendiagramm, Säulendiagramm,...): Metricsgraphic

Javascript | NodeJS

Understanding NodeJS und NodeJS für Anfänger.

Javascript | Build-Tools

NPM als Build-Tool und Grunt ist Mist. Letztere These kann ich unterstützen. Grunts-Konfiguration ist aus meiner Sicht nicht sehr intuitiv. Vielleicht bin ich aber zu sehr ANT-infiziert.

JSF Bashing

Einen interessanten Beitrag zu JSF: Why you should avoid JSF. In vielen Punkten gebe ich dem Autor Recht. Allerdings kann ich mit JSF trotzdem wunderbare Webseiten erstellen, ohne z.B. tief in Javascript einsteigen zu müssen oder zu wissen wie eine Single-Page Applikation funktioniert. Im Gegenzug muss ich verstehen, wie JSF funktioniert. Ebenfalls nicht trivial. Ein Vorteil von JSF gegenüber einer S(ingle)P(age)A(pplication) ist die Behäbigkeit der JSF Spezifikation gegenüber den ziemlich umtriebigen Javascript Frameworks. Was gleichfalls als Nachteil aufgefasst werden kann. Am Ende zählen dann die verschiedenen äußeren Faktoren wie Lebenszyklus, Entwicklungszyklus, Entwicklerteam, Sofware-Plattform, Kunde, etc.

Online | Browser Editor

Artikel verfassen: Hackpad

Java | Versionen...

Eine Übersicht über die verschiedenen Java Versionen: Baeldung Java 8.

Jenkins, Maven und das Deploy-Target

Vor kurzem habe ich einen meiner älteren Rechner reaktiviert und dort das aktuelle 64-Bit Ubuntu aktualisiert. In dem Zuge wurde das alte 32-Bit Vista entfernt und es standen zum ersten mal nach vielen Jahren die vollen 4 GB Hauptspeicher zur Verfügung. Aber das nur am Rande. Im Anschluss habe ich Jenkins installiert und meine Projekte konfiguriert. Jenkins soll alle meine Build-Artefakte bauen, das Ergebnis in einem Maven Remote-Repository zur Verfügung stellen und im Anschluss die Projekt Homepage per site-deploy aktualisieren. Der Zugriff auf den Remote-Server schlug aber regelmäßig mit der folgenden Fehlermeldung fehl:

The host was not known and was not accepted by the configuration

bzw.

Caused by: com.jcraft.jsch.JSchException: reject HostKey

Was habe ich alles versucht: Ich habe die SSH Schlüssel in Jenkins hinterlegt, ich habe das SSH Passwort in Jenkins hinterlegt, ich habe mich in die Maven-Konfiguration eingelesen (z.B. http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html). Das hat aber zunächst alles nicht geholfen. Hier die Lösung: Man loggt sich als Jenkins User auf dem Build-Rechner ein und baut das Projekt per Kommandozeile:

sudo su jenkins
cd ~jenkins/jobs/[PROJEKT_NAME]/workspace
~jenkins/tools/hudson.tasks.Maven_MavenInstallation/maven3/bin/mvn clean deploy

Jetzt den neuen SSH-Server akzeptieren, und wenn die SSH-Konfiguration korrekt ist, kann der Build über die Web-Oberfläche von Jenkins gestartet werden. Fazit: Bei SSH-Build Fehlern der Jenkins-GUI nicht vertrauen und zunächst das Problem per Kommandozeile lösen.

Maven Problem

Die aktuelle Maven Version 3.2.5 hat ein Problem mit dem Download von Artefakten aus Remote-Repositories. Genauer: In der Deployment-Phase, wenn die Datei maven-metadata.xml zu dem entsprechendem Artefakt geladen wird. Die dafür verantwortliche Bibliothek Wagon erwartet zu viele Bytes und hängt in einer Warteposition fest. Hier ein Beispiel:

[INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ master-pom ---
Uploading: scp://maven.gluehloch.de/var/www/maven.gluehloch/repository/de/awtools/master-pom/2/master-pom-2.pom
Uploaded: scp://maven.gluehloch.de/var/www/maven.gluehloch/repository/de/awtools/master-pom/2/master-pom-2.pom (16 KB at 13.1 KB/sec)
Downloading: scp://maven.gluehloch.de/var/www/maven.gluehloch/repository/de/awtools/master-pom/maven-metadata.xml
293/292 B

Wagon erwartet 293 Bytes. Die Datei ist aber nur 292 Bytes groß. Die Lösung sieht so aus, dass man die JARs wagon-*-2.8 aus dem LIB Verzeichnis der Maven Installation entfernt und diese durch die Version 2.4 ersetzt. Diese sind z.B. Bestandteil von Maven-3.1.1 und können von dort kopiert werden. Ein Test in dieser Konstellation war auf meinem System erfolgreich (Maven 3.1.5).

Zu diesem Thema gibt es bereits ein Issue: MDEPLOY-177