Aber der Reihe nach.

SASS

So schön CSS ist, so alt und stupide ist der Spielraum zum entwickeln und konzipieren. CSS kann keine Vererbung, keine Strukturierungen, keine Kapselungen bzw. Mixins. Das einzige, was CSS kann: eine Aneinanderreihung von Tags, bspw. #element ul > li

Mit SASS ist das alles möglich. Es sind hierarchische Strukturen möglich, man kann Mixins (Kurzanweisungen für ein Set von Funktionen/Attributen, Stichwort: Browser-Cross-Features) oder endlich Variablen im CSS nutzen. Der Code-Syntax ist dabei eine Erweiterung von CSS3* (d.h. CSS selber ist weiterhin möglich) und wird üblicherweise in .scss-Dateien abgelegt. Jedes öffentlich zugängliche Stylesheet muss dann in ein “normales” CSS umgeschrieben werden, das erledigt SASS wahlweise auf Knopfdruck oder mit einem Watchdog (Befehl watch). Mit letzterem geschieht die Generierung on-the-fly, d.h. man kann zwischen SCSS und Browser genauso wechseln wie beim guten alten CSS.

* So lange man natürlich kein CSS3 nutzt, ist man auch CSS2 kompatibel.

Compass

Als Erweiterung für SASS gedacht, erweitert Compass das Funktionsspektrum um einige hilfreiche CSS(3)-Features. Die Referenz zeigt stets den aktuellen Stand und auf GitHub sind die Sourcen offen zugänglich. Um beispielsweise die mittlerweile zahlreichen (6!) vendor-spezifischen Anweisungen eines linearen Gradienten (hier: weiß zu schwarz) zu erzeugen, reicht das simple Mixin linear-gradient(color-stops(white, black)).

Nett: Als Pull bekam das Projekt auch schließlich einen experimentellen Hack, damit Gradienten out-of-the-box im IE6-8 funktionieren. So funktioniert Open Source.

PIE

CSS3PIE ist eine winzige Library, die in Form einer HTC (so genannte HTML Components, eine microsoft-spezifische JavaScript-Datei) weitestgehend die CSS3-Features border-radius, box-shadow und linear-gradient bereitstellt.

In Compass ist PIE optional verfügbar. Mit der Ergänzung einer Zeile SCSS-Code ist damit ein runder, schattierter Button real.

Beispiele

Da war noch was…

CSS3PIE wurde dieses Jahr ein Teil von Sencha. Da ist es nicht verwunderlich, dass Sencha selber für ihren Theme-Generator (Bestandteil der Sencha SDK Tools)  für ExtJS/SenchaTouch auf Compass, PhantomJS u.a. setzt.

Unter dem Titel “Suche in Chrome per type=search anmelden” fand ich die Tage einen netten Hinweis von Markus. Es geht darum, dass der Chrome automatisch Suchmaschinen hinzufügt. Auch ich dachte bisher, dass Google einfach nur eine gute Liste eingepflegt hat (bspw. mit amazon.de), aber mitnichten: Die Amazon.de-Suchmaschine ist bei mir nur deswegen drin, weil ich die Amazonseite besucht habe und Chrome dort eine Suchmaschine “gefunden” hat. Aber warum gerade Amazon.de? Warum dict.cc?

Markus erster Hinweis war, dass es mit dem neuen HTML-Inputfeld-Typ “search” zusammenhängt. Ein anderer Kommentator brachte noch OpenSearch ins Spiel.. und als meine ersten Tests überhaupt nicht fruchteten, setzte ich mich mal genauer an das Thema heran. Den Großteil des Ergebnisses habe ich bereits in Markus’ Beitrag als Kommentar geschrieben.

OpenSearch

Beginnen wir mit OpenSearch: Dies ist ein — noch nicht standardisierter — Entwurf für ein Dokument, welches die Metainformationen einer Suchmaschine beschreibt: Name, Beschreibung, URL-Pattern, Sprache, usw.

Ein solches OSDD (OpenSearch Description Document) sieht dabei vereinfacht und exemplarisch so aus:

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
<ShortName>Example</ShortName>
<Description>My example search engine</Description>
<InputEncoding>UTF-8</InputEncoding>
<Image height="16" width="16" type="image/x-icon">http://example.org/favicon.ico</Image>
<Url type="text/html" template="http://example.org/index.html#search={searchTerms}"/>
</OpenSearchDescription>

Damit ein Browser die OSDD auch finden kann, muss sie innerhalb des HTML-Heads als Metainformation eingefügt werden:

<link title="Example" type="application/opensearchdescription+xml" rel="search" href="http://example.org/opensearch.xml">

Voilá! Ein Firefox findet damit bereits die Suchmaschine und bietet, wenn man auf den kleinen Pfeil unter dem aktuellen Suchmaschinen-Icon klickt, das Hinzufügen der neuen an. Das gilt im Übrigen auch für den Internet Explorer 8. Ab FF 2 und IE7 kann zudem explizit auf eine solche OSDD per JavaScript verwiesen werden:

window.external.AddSearchProvider("http://example.org/opensearch.xml");

Autodiscovery Mode in Chrome

Google Chrome erkennt auch diese OSDD, stellt aber zur Zeit keine geeignete UI wie etwa Firefox oder Internet Explorer zur Verfügung. Vielmehr werden hier die Suchmaschinen automatisch erkannt, eingetragen und über die kombinierte Adress- und Suchleiste zur Verfügung gestellt.

Der Trigger für den Autodiscovery Mode ist dabei zwar ein INPUT-Field mit dem Typ “search” oder wahlweise mit dem Typ “text” und dem Namen “s”. Der eigentliche Clou Witz an der Sache ist jedoch, dass Chrome dieses HTML-Element explizit auf der Startseite der Domain erwartet. Es muss also auf der example.org/index.html oder example.org/startseite.jsp auftauchen. Funktioniert die OSDD prinzipiell von allen Seiten aus, so funktioniert der Autodiscovery Mode in keinem (virtuellen) Unterverzeichnis.

Interessanterweise spielt es aber keine Rolle, wie lange die Seite angezeigt wird. Liegt also bspw. eine example.org/index.html vor, die einen Meta-Refresh nach 0 Sekunden (sprich: sofort) macht, dann funktioniert der Autodiscovery Mode dennoch. Zusätzlich kann man das Formular auch unsichtbar machen, dies hat keine Auswirkungen.

Im Grunde reicht also dieses Schnippselchen, sofern man keine adäquate oder sinnvolle Startseite hat:

<form style="display: none;"><input type="search" name="s" /></form>

Die eigentliche Konfiguration holt sich Chrome wiederum aus der OSDD.

Drawbacks

• Apple Safari scheint bis dato keinerlei native Unterstützung für OSDD oder vergleichbares zu haben. Am nächsten kommt das Plugin Inquisitor.
• Internet Explorer 9 scheint auf den ersten Blick keine Unterstützung für OSDD zu haben. Evtl. habe ich es aber auch noch nicht gefunden?
• Opera hat auch keine Unterstützung.

• Spezialfall: Im Verbund mit einem Suchparameter via Hash (Ajax/RIAs) wird bei Firefox nur der location.hash ausgetauscht (die Applikation bleibt). Google hingegen veranlasst einen kompletten neuen Request auf location.href, womit die gesamte Applikation neu geladen wird.

tl;dr: in a nutshell und lost facts

• Die opensearch.xml stellt Metainformationen für eine Suchmaschine bereit und muss auf der HTML-Seite verlinkt werden.
• Für den Autodiscovery Mode von Chrome muss auf einer Seite im Domain-Root ein INPUT-Feld “type=search” oder “name=s” vorhanden sein.
• Das Formular respektive Feld muss weder für den Benutzer sichtbar sein (CSS), noch lange angezeigt werden (Redirect nach 0 Sekunden).
• Manuelles Hinzufügen über eine API in nahezu allen aktuellen Browsern möglich.
• Es können mehrere Suchmaschinen je Seite verwaltet werden (betrifft OSDD).

Links

• OpenSearch Supported Clients
• OpenSearch Developer Best Practices

Update: Martin Thoma hat einen englischen Artikel (http://martin-thoma.com/search-engine-autodiscovery/) geschrieben, der auf diesem basiert. Ergänzende Informationen sind zum Beispiel die aktualisierten Kompatibilitäten (IE7).

Nein, hatte er nicht. Sowohl die Subversion-Timeline als auch das eigentliche Repository zeigten alles korrekt an — Puh! Das bedeutetet jedoch, das aus irgendeinem Grunde die Synchronisation mit Git in die Hose gegangen war. Leider brachte auch das Re-Syncen nichts.

Erst das nähere Betrachten in einem visuellen Darstellung mit Hilfe von GitX brachte eine Erkenntnis: Aus irgendeinem Grunde war an einem bestimmten Tag X zwischen zwei Commits ein Merge des Release-Branches in den Hauptzweig “master/trunk” geschehen. Da ich mich an eine solche Aktivität nicht erinnern konnte (abgesehen der Tatsache, dass mir das mit git-svn auch als Kunststück vorkam), ergab das ein großes Fragezeichen… bis ich dann sah, was die besagten Commits in der SVN-Timeline waren.

Aus historischen und situationsabhängigen Gründen wurde damals ein unkonventionelle Weg eingeschlagen werden: Aus /trunk wurde Release 1.0; /trunk wurde verschoben (bzw. gelöscht, außerhalb des Standard-SVN-Schema) und schließlich /branches/new-release nach /trunk verschoben. An dieser Stelle verschluckt sich die Git-SVN-Bridge, und alle drei Branches verschmelzen zu einem gleichen Tree (nämlich den Master/Trunk).

Und die Lösung des Problems? Einmal abgesehen davon, dass natürlich die Aktion im SVN-Repository nicht gerade brilliant war, lässt sich dies über die .git/config lösen. (Hinweis: Ein einfaches git remote rm löst das Problem nicht, weil es git-svn remotes sind.)

[svn-remote "1.1-RELEASE"]
    url = svn+ssh://your-server/home/svn/project-name/branches/1.1-RELEASE

fetch = :refs/remotes/1.1-RELEASE
oder auch

[svn-remote "1.1-RELEASE"]
    url = svn+ssh://your-server/home/svn
    fetch = project-name/branches/1.1-RELEASE:refs/remotes/1.1-RELEASE

IE9 has none of them, nor does it have any validation, or ranges or the new types… and worst of all for my Uploader widget, still, after all these years, does not support multiple file uploads. So the 99% isn’t 99% of all HTML5 features — it’s 99% of the tests that IE implemented. This is like writing your own test and bragging that you passed it.

Ein (weiterer) schöner Artikel über den Bullshit Microsofts. Obwohl der IE9 grundlegende und zahlreiche neue Features von HTML5 implementiert, fehlen im Vergleich zu den anderen Browsern noch etliche.. abgesehen davon, das auch diese noch nicht alles implementiert haben.

Insofern ist die Aussage einer 99% HTML5 (Test)-Abdeckung genauso viel aussagekräftig, wie das Entwickeln und Nutzen von 99 Testfällen bei Hunderten Fallunterscheidungen.

Wetten, dass demnächst etliche Zeitungen, Magazine oder gar Blogs von der überragenden HTML5-Kompatibilität der IE9 berichten werden?

Als Stichtag würde ich den 3.11.2010 vorschlagen. Ich stelle mir vor, dass an diesem Tag alle Entwickler, die ein Blog oder eine Seite betreiben, ein kleines Stück Code präsentieren, dass aus heutiger (oder vielleicht auch damaliger) Sicht total hirnverbrannt ist. Ein Stück Code, dass uns selbst die Schamröte ins Gesicht steigen lässt. Dabei ist egal, ob es sich um PHP, JavaScript, CSS, HTML, Java, C oder sonst etwas handelt. Es muss nur von euch sein und es darf nicht verändert werden (umeventuell doch als total verrückter Hund dazustehen ). Ein kleiner erläuternder Text sollte natürlich auch nicht fehlen.

Und das ist mein Beitrag, wohl einer meiner ersten Gehversuche in PHP. Der Quellcode entstammt einer Datei namens “functions.inc.php” [sic!]. Und es scheint so , also wäre es eine größere Anwendung gewesen, ich habe jedoch echt keine Ahnung mehr welche — vielleicht die erste PHP-Homepage in Eigenentwicklung? Die Datei hatte sich irgendwie auf meine “Informatik-Diskette” [sic!] (Oberstufenkurs) verirrt, von der ich tatsächlich noch ein Abbild hatte. Der Rest der Programmiersünden muss entweder (m)einen Backup-Aufräumaktionen oder einem vor einigen Jahren aufgetreten Backupmediumfehler zum Opfen gefallen sein. Zu meiner Verteidigung kann ich wohl nur sagen hoffen, dass dies einer erste Spielversion war und nie “produktiv” wurde.

Listing

Bitte in voller Länge genießen. Jede Zeile ist ein Genuss. *ankoppfass*

Unverändert, nur Benutzername/Passwort habe ich ausgeixt.

Datei: functions.inc.php (von 2002 oder 2003)

<?php
//conf.inc.php
//please don't change this file manually - go to your admin-area to change settings!!!
$listname="Meine Linkliste";
$listname2="Downloads";
$linkwidth="100%";
$addpagewidth="50%";
$catorder="name";
$incatsort="Hits";
$perpage="5";
$max_search="10";
$adminpw="a";
$max_desc_leng="500";
$html="ON";
$language="german.lang";
$timeformat="1";
 @include("global/$language"); // language-file
 @include("../global/$language"); // language-file
//connect.inc.php
// DON'T CHANGE THIS FILE MANUALLY - EDIT ONLY VIA ADMIN-AREA
$server="localhost";
$user="xxx";
$pass="xxx";
$mydb="xxx";
$db_prefix="xl_";
$db_prefix2="dl_";
function JPDiv ($a,$b) {
  $i=0;
  $j=0;
  while($j==0) {
    if(($a/($b*($i+1)))>1) {
      $i++;
    } else {
      $j = 1;
    }
  }
return $i;
}
function JPDatumZeit ($a) {
  $JPTag = array("Sonntag","Montag","Dienstag","Mittwoch","Donnerstag","Freitag","Samstag");
  $JPMonat = array("Januar","Februar","März","April","Mai","Juni","Juli","August","September","Oktober","November","Dezember");
  $JPDatumTag = $JPTag[date("w",$a)];
  $JPDatumMonat = $JPMonat[date("n",$a)-1];
  $JPDatumJahr = date("Y",$a);
  $JPZeit = date("H:i:s",$a);
  $b = $JPDatumTag . ", " . date("j") . ". " . $JPDatumMonat . " " . $JPDatumJahr . " [" . $JPZeit . "]";
return $b;
}
function JPDatumZeit2 ($a) {
  $JPDatumJahr = date("Y",$a);
  $JPZeit = date("H:i:s",$a);
  $b = date("j") . "." . date("w",$a)+1 . "." . $JPDatumJahr . " [" . $JPZeit . "]";
return $b;
}
class my_zugriff{
//Variablen für Zugangsdaten
var $user="xxx";		//Benutzername für den MySQL-Zugang
var $password="xxx";		//Passwort
var $host="localhost";	//Name (IP-Adr.) des Rechners mit MySQL
var $dbname="xxx"; 	//Name der Datenbank
//Weitere Variablen
var $db_verbindung=false; //Speichert die Verbindungskennung
var $sql_result=false; //Speichert die Kennung eines ausgewerteten SQL-Befehls
//Konstruktor definieren
function my_zugriff(){
   //Funktion verbinden wird bei Aufruf der Klasse ausgeführt
	 $this->verbinden();
}
//Falls keine Verbindung besteht,
//Verbindung aufbauen und Datenbank als Standard definieren
function verbinden(){
if ($this->db_verbindung==false){
   $this->db_verbindung = @mysql_connect($this->host, $this->user, $this->password);
   if(empty($this->db_verbindung)){
      $this->fehler("Beim Verbinden");
   }
   $auswahl = @mysql_select_db($this->dbname, $this->db_verbindung);
   if(empty ($auswahl)){
      $this->fehler("Beim Ausw&auml;hlen der DB");
   }
   return $this->db_verbindung;
}
}
//Gibt Fehlermeldung aus und beendet das Skript
function fehler($fehlerpunkt){
    echo $fehlerpunkt . " ist ein Fehler aufgetreten!<br>";
		echo mysql_error() . "<br>"; //Fehlerbezeichnung
		echo mysql_errno();	 	 		//Fehlernummer
		echo "</body></html>";		//Html-Tags schließen
		exit;
}
//SQL-Befehl ausführen
function sql_befehl($sql){
$this->sql_result = @mysql_query($sql, $this->db_verbindung);
if (empty($this->sql_result)){
	 $this->fehler("Beim Senden der Abfrage");
}
return $this->sql_result;
}
//Falls zuvor ein SQL-Befehl ausgeführt wurde,
//wird hier das Array mit den Datensätzen ausgegeben
function sql_daten(){
if(!empty($this->sql_result)){
		$sql_array=@mysql_fetch_array($this->sql_result);
		return $sql_array;
}else{
		$this->fehler("Beim Ausgeben der Datens&auml;tze");
}
}
//eig. Fkt
function sql_num_rows($sql){
$this->sql_befehl($sql);
$rows = MYSQL_NUM_ROWS($this->sql_result);
return $rows;
}
}
$db=new my_zugriff();
$db->sql_befehl("SELECT elem_string FROM elem_global WHERE elem_name='JPmyVersion'");
$myVersion_now = $db->sql_daten();
 $JPmyVersion = $myVersion_now[0];
?>

Selbstreflexion

• Struktur: globale Variablen
• Struktur/Aufbau:Â als Script noch okay, aber als Include? Oweh..
• Includes mittendrin
• Variabel- und Funktionsnamen multilingual
• Inhalt der Funktionen..
• kein gängiger Codestyle (ja, der Blog zeigt’s richtig an)
• Inline-SQL(!)

Kurzum: What the hell…?

Weitere via Google oder Twitter oder Facebook.

Wie gut der Browser jetzt ist, werden wir in den nächsten Tagen merken. Zu der Seite sei gesagt: Rein technisch scheint sie voll aufneuen Technologien zu setzen bzw. ohne Flash und Silverlight auszukommen. Die Seite ist schnell und auch ohne IE benutzbar. Im Gegensatz zu Apple haben sie es auch tunlichst vermieden, irgendwelche Browser künstlich auszuschließen, oder sollte ich etwas übersehen haben?

Mit Silverlight war es wohl schwieriger, mit Flash wohl unmöglich, noch mehr Performance rauszukitzeln. Schließlich soll der Browser IE9 ja zeigen, wie gut er ist. Also, keine Plugins, sondern pure HTML-Magie. Und CSS-Magie. Und Javascript-Magie.

Ein Schlag in Adobes Gesicht.

Es bestehen zwei lauffähige, fertige Projekte in Maven, welche beide auch vollwertige Artefakte bilden können.

Zum einen die Webanwendung — nennen wir sie hier mal webportal — mit einem WAR-Artefakt, etwa für einen Tomcat. Ob das Artefakt als Snapshot oder Release gemacht wird, ob es nur generiert oder auch in ein Repository deployt wird, ist hierbei nicht von weiterer Bedeutung.

Zum anderen die normale Clientanwendung — nennen wir sie doch einfach userclient — mit einem JAR-Artefakt. Wichtig ist natürlich, dass hier eine startfähige Main-Klasse vorhanden ist. Dies sollte jedoch der Regelfall sein, daher nur der formale Hinweis.

Zusammengefasst, und der Auftrag an dieses Howto ist also: Wie konfiguriert und erweitert man den Buildzyklus in welchem Projekt an welcher Stelle am geschicktesten, um auf einfachem Wege die JAR-Datei userclient in die Webanwendung webportal als Java Webstart zu integrieren. Dabei ist es hilfreich, wenn man via pom.xml (und natürlich der Macht der Properties) die Versionen spezifizieren kann. Der gesamte Prozess von auswählen, signieren und ausliefern soll dabei automatisch und ohne weiteres Eingreifen des Entwicklers geschehen können. Idealerweise sollte das ganze auch optional sein — dazu gibt es dann mehr unter “Optimierungen und Verbesserungen”.

Die Grundlagen

Ich möchte jetzt nicht viel über die Grundlagen verlieren, nur so viel sei gesagt. Aus Sicht von Maven ist die Konfiguration “nur” ein weiteres Plugin von vielen. Daraus ergibt sich natürlich auch die Möglichkeit, via Properties oder Profilen die Konfiguration sehr dynamisch zu halten. Webstart ist eine Technik, die an sich nichts mit Maven zu tun hat. Man kann auch “händisch” seine Jar-Datei über eine URL verfügbar machen. Man muss dann jedoch alles selber und richtig machen: Versionisierung, Signierung und Deployment. Die Signierung ist gerade dann wichtig, wenn die Applikation erweiterte/volle Rechte benötigt.

Die Möglichkeiten

Es gibt eine Reihe von Maven-Plugins, die einen unterschiedliche Ansätze und Lösungen bieten.

Das Maven Jar Plugin bietet etwa unter anderem die Möglichkeit, die Jar-Dateien zu signieren. Dies wäre jedoch nur die halbe Miete, da weder die Jar-Dateien bekannt noch auslieferbar sind. Auch das Keytool plugin ist nicht vollständig, denn es unterstützt zwar das Keystore gestützte signieren, aber auch nicht mehr. Wohl aber können diese Plugin als Basis für andere dienen.

Weitaus mehr Funktionen kann das Webstart Maven Plugin bieten. Es gibt verschiedene Arten der Erzeugung der Jnlp-Datei und dem damit verbundenen Sammeln, Bestimmen und Signieren der Abhängigkeiten in Form weiterer Jars oder Classfiles. Es ist auch ein hilfreiches Plugin, wenn man aus einem Projekt heraus direkt Jnlp & Ressourcen erzeugen will.

In diesem Howto ist aber vor allem ein Ziel von Relevanz:Â Die Variante mit dem Jnlp-Download-Servlet: das Goal webstart:jnlp-download-servlet.

Dieses Goal erzeugt im Buildprozess ein weiteres Verzeichnis mit den Ressourcen des userclients und der dazugehörenden Jnlps. Ein spezielles Servlet übernimmt die Auslieferungen.

Die Konfiguration im Projekt userclient

Das Projekt muss und sollte nicht “wissen”, dass es über Webstart irgendwo eingebunden wird. Daher sind keine Änderungen nötig. Wohl aber muss bekannt sein, wie die aktuelle bzw. die gewünschte Version ist und ggf. das Maven-Repository der Deploys.

Die Konfiguration im Projekt webportal

Das webportal muss hingegen durchaus von der Existenz des userclients wissen, denn jenes es soll ja in diese Webanwendung integriert werden. Die Konfiguration besteht im Wesentlichen aus drei Schritten: JnlpDownloadServlet-Abhängigkeit einfügen, Servlet in der web.xml registrieren und Build-Plugin in der pom.xml konfigurieren.

JnlpDownloadservlet (pom.xml)

Das Maven-Paket findet sich unter dem Namen com.sun.java.jnlp bzw. jnlp-servlet wieder. Als einfache Abhängigkeit ist es damit im Classpath und beispielsweise in der web.xml verwendbar. Weitere Informationen.

<dependency>
    <groupId>com.sun.java.jnlp</groupId>
    <artifactId>jnlp-servlet</artifactId>
    <version>5.0</version>
</dependency>

web.xml

Zur Basiskonfiguration muss nur das Servlet registriert und mit einem URL-Pattern verknüpft werden. Das klingt trivial, und das ist es auch.

<servlet>
  <servlet-name>JnlpDownloadServlet</servlet-name>
  <servlet-class>jnlp.sample.servlet.JnlpDownloadServlet</servlet-class>
</servlet>
<servlet-mapping>
  <servlet-name>JnlpDownloadServlet</servlet-name>
  <url-pattern>/webstart/*</url-pattern>
</servlet-mapping>

Damit wird die URL domain.tld/context/webstart an das Servlet gemappt. Dadurch kann das Servlet auch auf “virtuelle Dateianfragen” reagieren, etwa nach Jar-Dateien ohne Versions-Qualifkation (obwohl sie als versionierte Artefakte vorliegen).

Die Konfiguration lässt noch einige Dinge erweitern, verändern und tweaken (siehe Absatz Optimierungen und Verbesserungen). Für den Haupteinsatzzweck – das Bereitstellen einer oder mehrerer Jars via Webstart ist das jedoch völlig ausreichend.

Weitere Informationen bei Oracle/Java. Und weitere Informationen bei Codehaus.

pom.xml

Neben der Abhängigkeit des JnlpDownloadServlet muss das eigentlichen Maven Webstart Plugin für seinen Einsatz konfiguriert werden. Das Build-Plugin benötigt zudem noch ein Template (für die Generierung der Jnlp), die wird weiter unten beschrieben.

Zur Grundkonfiguration gehört:

1. Wo liegt das Jnlp-Template?
2. Wie heißt der Ausgabename der Jnlp?
3. Welche Abhängigkeiten gibt es für das Paket — hier wäre das der userclient?

Des Weiteren lässt sich bestimmen, ob etwa weitere (transitive) Abhängigkeiten mitausgeliefert werden sollen (bei Webstart ist das wohl meist sinnvoll), ob die Ressourcen signiert werden sollen und ob alles nochmals komprimiert deployt werden soll. Weitere Informationen.

Prinzipiell ist man weder auf eine Abhängigkeit pro Paket/JNLP beschränkt noch auf eine JNLP pro Plugin-Call geschweige denn des gesamten Projekts. Über das Konfigurationsschlüsselwort commonJarResources können sogar gemeinsam verwendete Abhängigkeiten definiert werden.

Da der userclient erweiterte Rechte benötigt, müssen alle Classfiles und Jars signiert werden. Wahlweise verwendet dafür einen vorhandenen Keystore oder erstellt einen neuen. Für diese Zwecke wird pro Buildvorgang ein neuer Keystore angelegt, damit signiert und danach wieder gelöscht.

Die Execution ist sinnigerweise process-resources mit dem Goal jnlp-download-servlet, denn streng genommen sind es ja nur weitere Ressourcen.

<plugin>
  <groupId>org.codehaus.mojo.webstart</groupId>
  <artifactId>webstart-maven-plugin</artifactId>
  <executions>
    <execution>
      <phase>process-resources</phase>
      <goals>
        <goal>jnlp-download-servlet</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <outputDirectoryName>webstart</outputDirectoryName>
    <excludeTransitive>false</excludeTransitive>
    <jnlpFiles>
      <jnlpFile>
        <templateFilename>template.vm</templateFilename>
        <outputFilename>UserClient.jnlp</outputFilename>
        <jarResources>
          <jarResource>
            <groupId>org.example.userclient</groupId>
            <artifactId>example-userclient</artifactId>
            <version>1.0.0</version>
            <mainClass>org.example.userclient.Main</mainClass>
          </jarResource>
        </jarResources>
      </jnlpFile>
    </jnlpFiles>
    <outputJarVersions>true</outputJarVersions>
    <verbose>false</verbose>
  </configuration>
</plugin>

Mit dieser Konfiguration werden die Jar-Dateien inkl. Abhängigkeiten in das Verzeichnis webstart gepackt — remember? wie in der web.xml. Das Template heißt template.vm und ist per default unter src/main/jnlp zu finden. Dies ließe sich mit templateDirectory überrschreiben. Der Name der Jnlp lautet UserClient.jnlp, damit ergibt sich die spätere Web-Url: http://example.org/context/webstart/UserClient.jnlp. Die eigentlichen Ressourcen und Abhängigkeiten werden in jarResources/jarResource definiert. Bei einfachen Projekten wird dies nur eine Ressource sein, theoretisch wären auch mehrere möglich. Die Konfiguration ähnelt der der dependencies.

template.vm

Im Prinzip ist das Template eine unfertige Jnlp. Sie wird durch das Maven Plugin mit den endgültigen Daten befüllt. Da bereits die pom.xml über einige Informationen wie Projektnamen, -beschreibung oder -url verfügt, können so sehr einfach die Daten mit übernommen werden. Man kann jedoch auch die Platzhalter entfernen — es ist eben nur ein Template.

Ein Beispiel könnte so aussehen:

<jnlp spec="$jnlpspec" codebase="$$codebase">
  <information>
    <title>$project.Name</title>
    <vendor>$project.Organization.Name</vendor>
    <homepage href="$project.Url"/>
    <description>$project.Description</description>
    <icon href="../resources/images/logo.png"/>
    <icon href="../resources/images/logo.png" kind="splash"/>
#if($offlineAllowed)
<offline-allowed/>
#end
  </information>
#if($allPermissions)
<security>
<all-permissions/>
</security>
#end
  <resources>
    <j2se version="$j2seVersion"/>
$dependencies
  </resources>
  <application-desc main-class="$mainClass"></application-desc>
</jnlp>

Mehr oder weniger simpel, oder? Eventuell sollte man die Adressen zum Logo anpassen (oder entfernen); gerade die letzte Zeile erzeugt einen netten Splashscreen (Ladebild) während dem Starten und Laden der Anwendung. Das ist immer gerne willkommen.

Wichtig: Im Gegensatz zu dem einen oder anderen Beispiel ist es hierbei wichtig, dass die Variable $$codebase heißt. Nicht etwa ${codebase}. Insgesamt sind in der JNLP — sofern man sie über das Servlet ausliefert — folgende Variablen verfügbar: codebase, name, context und site.

Optimierungen und Verbesserungen

“Einmal signiert, bitte!”

Um all-permissions nutzen zu können, müssen die Jars und Classfiles signiert werden. Das erreicht man, indem man unter dem XML-Knoten configuration einen Knoten sign anlegt, etwa:

<sign>
	<keystore>keystore.ks</keystore>
	<keypass>pass</keypass>
	<storepass>pass</storepass>
	<alias>userclient</alias>
	<validity>36500</validity>
	<dnameCn>UserClient</dnameCn>
	<dnameOu>Software Development</dnameOu>
	<dnameO>The Example Networks</dnameO>
	<dnameL>Cologne</dnameL>
	<dnameSt>NRW</dnameSt>
	<dnameC>DE</dnameC>
	<verify>false</verify>
	<keystoreConfig>
		<delete>true</delete>
		<gen>true</gen>
	</keystoreConfig>
</sign>

Hierbei wird der Keystore lokal erzeugt (keystoreConfig/gen ist true) und nach Gebrauch wieder gelöscht (keystoreConfig/delete ist true). Selbstverständlich kann man hier auch a) noch einen Keystore-Generator (s.o.) nutzen oder einen fest konfigurierten, dauerhaften. Dann sollte man natürlich die Konfiguration entsprechend anpassen.

“Bitte Optional” — alles in ein Profil

Die Profile in der pom.xml sind ein mächtiges Werkzeug, um bestimmte Features zusammenzufassen. So könnte man das gesamte Build-Plugin in ein Profil — etwa mit dem Namen with-webstart — ablegen.

Selbst die Abhängigkeit zum JnlpDownloadServlet kann man dorthin verlagern — wenn man daran denkt, dass in diesem Falle auch die web.xml dynamisch erstellt werden soll.

Macht der Properties

Man kann die Gesamtkonfiguration um einiges komfortabler machen, indem man Properties einführt und deren Standardwerte “oben” in der pom.xml definiert. Gute Kandidaten hierbei wären: userclient.version, keystore.file, keystore.keypass, keystore.storepass und keystore.alias.

Noch mehr in Sachen Jnlp

In der web.xml kann des Weiteren das verhalten des JnpDownloadServlet verändert werden. Ein Überblick über einige Möglichkeiten:  Mimetypen ändern, Dateiendungen ändern, weitere Mappings anlegen, spezielles Debugging.

… ist eine rein HTML5-Anwendung, welche sich auf Basis einer Adresse, den dazugehörigen Google Earth und Google StreetView Daten einen Musicclip “rendert”. Sehr kreative Idee!

Funktioniert mit einem aktuellen Chrome, Chromium oder auch Safari. Wohl aber dem, der ein bisschen Power im Arsch/Rechner hat.

Entstammt aus den Google Experiments, und der Chrome ist auch zu empfehlen (vor allem bei leistungsschwächeren Rechnern).

Wie auch immer: Ich habe auf die Schnelle eine Extension geschrieben, welche die Flash-Player auf Tagesschau.de automatisch in entsprechende HTML5-Tags umwandelt. Der Code ist zur freien Verfügung unter GitHub einsehbar, der Download ist ebenfalls dort unter Downloads zu finden.

Beispiel anhand der Seite http://www.tagesschau.de/ausland/swift172.html

Tagesschau mit Flash

Tagesschau mit HTML5

Der Code ist wenig-bis-gar-nicht dokumentiert, sollte aber bei der mehr oder weniger jQuery-Trivilität nicht notwendig sein. Eine Adaption für Chrome/Firefox sollte einfach sein. Wie man im Code sieht, habe ich sogar das Ogg-Format ausgelesen.

Resultat: HTML

Anregungen sind gerne willkommen.

Derzeit werden nur die Filme auf normalen Artikeln ausgetauscht; keine Sidebars, mutmaßlich auch keine Extra- oder Spezialseiten. Außerdem ist – derzeit – die Kodierung auf H.264-High und Ogg fest eingestellt. Flash lädt im Vergleich immer H.264-Medium.

Der Chuck Norris im JavaScript.

Beispiel?

I give permission for IBM, its customers, partners, and minions, to use JSLint for evil.