Freitag, 25. Juni 2010

OSGi-Bundles bauen mit Tycho

Hallo,

ich habe mit Hilfe des Tutorials von Mattias Holmqvist (Teil 1, Teil 2 und Teil 3) unser Projekt vom Headless PDE-Build bzw. BND-Build umgestellt auf Tycho.

Zunächst einmal: Es geht erstaunlich einfach. Das Tutorial ist unglaublich präzise. Und tycho funktioniert schon in der Version 0.8 sehr gut, die gerade die aktuelle ist (0.10-SNAPSHOT wollte ich nicht nehmen).

Aber natürlich gab es auch noch ein paar Probleme, die kein noch so gutes Tutorial aus der Welt schaffen kann. Ich liste die einfach mal hier auf, damit andere bei ähnlichen Problemen eine Hilfe bekommen:

Source- und Target-Versionen für den Code


Wir verwenden für unseren Source Java Version 6-Features, insbesondere @Override-Annotationen auch für Methoden, die Interface-Methoden überschreiben. Das resultiert dann in einem Fehler "must override a superclass method".

Das wollte ich zunächst mit einer Plugin-Konfiguration in der parent-pom lösen, hier hat aber Tycho in der Version 0.8 noch ein Problem.

Aber das osgi-compile-Plugin verwendet aber die gleichen Properties zur Konfiguration wie das "normale" compile-Plugin, ich konnte also einfach die Properties maven.compiler.source=6 und maven.compiler.target=6 in der Parent-POM setzen.

In zukünftigen Versionen wird Tycho diese Information aus dem Manifest ziehen.

eclipse-application


Wir hatten bisher die .product-Datei in einem ganz normalen Bundle zusammen mit ein paar Java-Klassen, den entsprechenden Ressourcen etc. Tycho baut ein eclipse-application-Bundle aber nicht als Bundle, so dass es ich einfach genau so gemacht habe, wie Mattias Holmqvist es als sein Standard-Vorgehen beschreibt: Ich habe ein eigenes Plugin in der Eclipse IDE angelegt, das nur die foo.bar.product-Datei enthält. Dieses muss noch nicht einmal als PDE-Projekt angelegt sein. Noch schnell eine POM für dieses Projekt geschrieben (wie beschrieben in Teil 2) und in die Parent-POM eingetragen.

Verschachtelte Projekte


Tycho arbeitet im Moment nur mit P2-Repositories, nicht aber mit dem Maven-Repository. Es ist also nicht möglich, die verschiedenen Layer einer Applikation aufeinander aufbauend in separaten Builds zu bauen. Also muss die Parent-POM wirklich alle Module auf einmal bauen.

Soweit dazu, aber selbst mit diesen kleinen Problemchen hatte ich mit tycho meine Eclipse-Applikation schneller gebaut als mit dem PDE-Build oder mit dem BND-Plugin.

Montag, 13. Juli 2009

OSGi-Bundles bauen mit Eclipse und Maven


Neu: Ich habe jetzt mal Tycho ausprobiert, damit ist alles besser :)

Allerdings mache ich dafür kein neues Tutorial, das von Mattias Holmqvist (Teil 1, Teil 2 und Teil 3) ist schon ziemlich perfekt. Meine Erfahrungen damit habe ich unter OSGi-Bundles bauen mit Tycho beschrieben.


---
Alter Post (Vorsicht, mir hat's Groß- und Kleinschreibung zerlegt und das Aufräumen lohnt aus oben beschreibenem Grund nicht mehr) :


OSGi-Bundles und Eclipse Plugins zu bauen war bisher immer sehr umständlich und fehleranfällig. Das bringt mich ja zu der Haltung, dass ich OSGi eher vermeiden würde. Insbesondere bringt es ja in der Regel auch keinen Business-Value. Anderes Thema, ich bin nun mal durch das Umfeld gezwungen, Plugins für die Eclipse Rich Client Platform zu bauen.

Meine Randbedingungen sind Folgende: Ich möchte in Eclipse entwickeln und dort auch alle Möglichkeiten der PDE nutzen. Andererseits ist es für mich keine Option, fertige Bundles durch einen Entwickler aus seiner IDE exportieren zu lassen. Ich nutze nämlich sowieso ein automatisches Build-System (schließlich bin ich nicht alleine auf der Welt, sondern kooperiere mit anderen, zum Teil verteilt sitzenden Kollegen), um Continuous Builds und Nightly Builds zu machen (siehe mein letzter Post). Dort möchte ich die Bundles über Maven bauen. Bisher haben wir das hier in der Firma über den automatisierten PDE-Build gemacht, der Prozess ist aber höchst umständlich und fehleranfällig.

Mit dem bnd-Tool und dem maven-bundle-plugin aus dem Apache Felix-Projekt gibt es jetzt aber eine spannende und benutzbare Option. Spannend deswegen, weil bnd einen völlig neuen Weg geht - es basiert nämlich nicht (nur) auf Deklarationen, sondern analysiert den compilierten Code, um Abhängigkeiten zu entdecken und in die MANIFEST.MF einzutragen.

Jetzt zur Lösung: Da ich nicht nur ein Bundle verwende, habe ich eine "common-pom.xml" als gemeinsame Parent-POM meiner Bundle-Projekte.

Dort verwende ich folgenden Eintrag unter Plugins:



<plugin>
  <groupid>org.apache.felix</groupid>
  <artifactid>maven-bundle-plugin</artifactid>
  <extensions>true</extensions>
  <configuration>
    <manifestlocation>META-INF</manifestlocation>
    <instructions>
      <bundle-symbolicname>${pom.groupId}.${pom.artifactId};singleton:=true</bundle-symbolicname>
      <bundle-activator>${bundle.activator}</bundle-activator>
      <embed-dependency>*;scope=compile|runtime;type=!pom,inline=false</embed-dependency>
      <embed-transitive>true</embed-transitive>
      <embed-directory>lib</embed-directory>
      <import-package>${bundle.import-packages}*;resolution:=optional</import-package>
    </instructions>
  </configuration>
</plugin>

Die notwendigen Properties habe ich in der Parent-POM wie folgt definiert:


<properties>
  <bundle.activator>${pom.groupId}.${pom.artifactId}.internal.Activator</bundle.activator>
  <bundle.import-packages></bundle.import-packages>
</properties>


Für das Zusammenspiel mit Eclipse als IDE sorgen dabei einige Einträge: Zunächst verwende ich als manifestLocation natürlich den "default"-Pfad von Eclipse (META-INF) und nicht den maven-default unter target.

Zum anderen verwende ich ein "Embed-Directory" (lib), in das ich per maven-dependency-plugin alle notwendigen Abhängigkeiten (d.h. 3rd-Party-Libraries, die ich nicht zu OSGi-Bundles konvertiere) kopiere. Der entsprechende Abschnitt der Parent-POM sieht wie folgt aus:

<profiles>
  <profile>
    <id>eclipse</id>
    <build>
      <plugins>
        <plugin>
          <artifactid>maven-clean-plugin</artifactid>
          <executions>
            <execution>
              <id>clean-dependencies-eclipse</id>
              <phase>process-resources</phase>
              <goals>
                <goal>clean</goal>
              </goals>
              <configuration>
                <filesets>
                  <fileset>
                    <directory>${basedir}/lib</directory>
                    <includes>
                      <include>**/*</include>
                    </includes>
                  </fileset>
                </filesets>
              </configuration>
            </execution>
          </executions>
        </plugin>
        <plugin>
          <artifactid>maven-dependency-plugin</artifactid>
            <executions>
              <execution>
                <id>copy-dependencies-eclipse</id>
                <phase>process-resources</phase>
                <goals>
                  <goal>copy-dependencies</goal>
                </goals>
                <configuration>
                <outputdirectory>${basedir}/lib</outputdirectory>
                <includescope>compile</includescope>
                <includescope>runtime</includescope>
                <excludetypes>pom</excludetypes>
              </configuration>
            </execution>
          </executions>
        </plugin>
      </plugins>
    </build>
  </profile>
  ...
</profiles>


Für ein konkretes Bundle sind jetzt "nur noch" relativ wenige Schritte notwendig:

Natürlich muss das Projekt die Parent-POM entsprechend referenzieren (ich mache das bei mir per relative-path wie folgt):



<parent>
  <groupid>de.vizmind</groupid>
  <artifactid>common</artifactid>
  <version>0.0.1-SNAPSHOT</version>
  <relativepath>../de.vizmind.common/pom.xml
</parent>


Als Packaging muss man bundle verwenden:

<packaging>bundle</packaging>


Jetzt kann man ganz wie gewohnt seine Dependencies eintragen, wobei die Compile und Runtime-Dependencies wie oben gesagt in den lib-Ordner kopiert werden und so für den PDE-Mechanismus von Eclipse verwendbar sind - dieser hat nämlich so seine Probleme mit den "Maven Dependencies" des m2eclipse-Plugins.

Abhängigkeiten zu anderen Bundles markiert man einfach mit dem Scope "provided", diese werden dann herangezogen, um die "import-packages" zu bestimmen, aber nicht mit in das Bundle kopiert.

Jetzt muss man gegebenenfalls noch die Properties aus der Parent-POM "überdefinieren", z.B. wenn man keinen Activator definiert hat (der default wird unter ${pom.groupId}.${pom.artifactId}.internal.Activator erwartet).

Wenn man Abhängigkeiten definieren muss, die sich nicht aus den class-Dateien ergeben, so ist das manuell über das Property "bundle.import-packages" zu tun. Da dieses Property einfach vor die automatisch bestimmten gehängt wird, muss man es (noch) mit einem Komma beenden, sofern es nicht leer ist. (Ein weiterer Punkt für Verbesserungen). In unserem Beispiel hier verwenden wir in einem Bundle spring und referenzieren in der context.xml einen PropertyPlaceholderConfigurer. Der Import für diese Klasse kann natürlich nicht automatisch aus .class-Dateien bestimmt werden, also muss er manuell hinzugefügt werden. (Ein weiterer Punkt für Verbesserungen - Automatische Analyse von Spring-Dateien).

Zusammen sieht das dann wie folgt aus:


<properties>
  <bundle.activator></bundle.activator>
  <bundle.import-packages>org.springframework.beans.factory.config,</bundle.import-packages>
  <!-- Close with "," if you have a non-empty list -->
</properties>


Jetzt ist mein Projekt fertig. Die Verwendung eines Profils (in der Parent-POM, siehe oben) sorgt dafür, dass ich mit folgendem Maven-Kommando ein Eclipse-Projekt anlegen kann, ohne dem eigentlichen Build später in die Quere zu kommen.

mvn eclipse:clean eclipse:m2eclipse process-resources compiler:compile bundle:manifest -Declipse.pde=true -Peclipse

Das Kommando ist noch etwas umständlich, evtl. mache ich später hier noch etwas "Feinarbeit". Für jetzt funktioniert es erst mal.

Das Projekt kann nun in Eclipse importiert werden. Einziger Wermutstropfen: Aktuell wird die .classpath-Datei noch nicht so aufgebaut, dass die embedded 3rd-Party-Libraries auch referenziert werden. Die muss man noch einmal "von Hand" in den Build-Path aufnehmen.

Damit ist der Weg frei, das Bundle in der Eclipse IDE zu verwenden und zu entwickeln.

Mit

mvn package

kann man nun das Bundle auch bauen, so dass auch dem automatisierten Build nichts mehr im Wege steht.


Ciao

Chris

Montag, 11. Mai 2009

Video vom Vortrag

Den Hudson-Vortrag hab ich gleich nochmal gehalten - beim Arbeitskreis Objekttechnologie Norddeutschland.

Diesmal gibt's auch ein Video davon.

Mittwoch, 18. März 2009

Vortrag bei der JUGHH: Continous Integration mit Hudson

Hallo!

Gestern habe ich einen Vortrag bei der Java User Group Hamburg über Continuous Integration mit Hudson gehalten. Die Folien dazu gibt's unten.

Wie üblich haben sich neben und nach dem Vortrag interessante Diskussionen ergeben, die im wesentlichen in zwei Richtungen gehen:

Zum einen ist der Build von Eclipse-Applikationen ein echter Schwachpunkt, für den jeder Lösungen sucht bzw. ähnliche Workarounds findet. Ein wirklich schwerwiegendes Problem dabei ist, dass man kaum verwertbare Dokumentation dazu findet. Ich werde versuchen, das in einem meiner nächsten Posts zu beheben und unseren Eclipse-PDE-Build-Prozess zu beschreiben. Die Einbindung in Hudson ist dabei Gott sei Dank nicht das Problem.

Zum anderen stellte sich einmal mehr heraus, dass auch das Bauen von Software immer wieder neue und interessante Facetten hat. Hudson kann ja mit mehreren Build-Prozessoren umgehen. Welche Build-Schritte kann man eigentlich parallelisieren? Welche müssen in jedem Fall erst nach einer Menge anderer Teil-Schritte bearbeitet werden. Wie synchronisiert man diese Builds. Wie testet man? Auch das sind Themen, auf die ich jetzt (noch) keine Antwort habe. Demnächst mehr.

Gute Nacht!

Continuous Integration mit Hudson
View more presentations from cb.betz.

Dienstag, 13. Januar 2009

Neues Jahr, neues Glück

So - neuer Vorsatz... eigentlich hab ich's ja nicht so mit Vorsätzen, aber dieses Jahr ist gut dafür. Unser Nachwuchs kommt und ich hab mir überlegt, dass es endlich Zeit ist, web2.0ig zu werden. Also nicht passiv, sondern aktiv. Selbst bloggen, twittern, flickrn und so weiter, was das Zeug hält. Was Nachwuchs und Web 2.0 miteinander zu tun haben? Erst mal gar nix. Außer dass ich natürlich drüber nachdenke, was mir wichtig ist und was ich gern mache. Und das werde ich hier mit allen teilen, die's interessiert.

Also kurz über mich - ich bin ja eigentlich schon Web 2.0. Viel im Internet unterwegs und schon eher das, was sich so gemeinhin Early Adopter nennt. Immer eher technisch, aber auch mit einem starken Bezug zum Nutzen, zu User und Usage Experience bis hin zum Marketing. Den Fokus auf Benutzbarkeit habe ich schon in meiner Promotion gehabt. Da ging es darum, wie man eLearning-Systeme durch Fachexperten mit einer möglichst geringen Einstiegshürde erstellen kann und wie diese dann nach und nach so wachsen, dass sie "intelligent" auf die Lerner reagieren können. Ich habe schon Expertensysteme entwickelt, Musikportale im Internet gebaut und auch größere Web-Systeme für Banken. Nicht gerade Web 2.0 - aber für die konservative Branche schon recht fortschrittlich. Manches davon habe ich in meiner eigenen Firma gemacht, manches bei einem der größten deutschen Interactive-Dienstleister.

Seit etwas über einem Jahr bin ich jetzt in einer ganz anderen Branche. Ich baue Software zur Kommunikationsanalyse in einer alteingesessen Hamburger Firma. Zum Thema Visuelle Analyse werde ich hier sicher noch das ein oder andere schreiben.

Samstag, 18. Oktober 2008

session building

hey, spannend. Es ist total egal, wie viele Leute sich für ein Thema interessieren. Die Themen werden immer in den Schedule gepinnt.

barcamp...

make wine tasting visible, accessible places, tomocos, theatre 2.0, 

Die Themen sind recht unterschiedlich und bei weitem nicht soooo technisch, wie die ursprünglich angekündigten Themen. Fragt sich, ob nur die Nerds ihre Themen schon vorher präsentieren?

Dienstag, 14. Oktober 2008

Website Navigation

Interessant, sollte man mal ausprobieren: Eine Website ohne eigene (hierarchische) Navigation, weil Benutzer die sowieso nicht benutzen. Stattdessen "teleportieren" sich die Benutzer mit Googles Hilfe von einer Website zur nächsten.

Das würde völlig neue Wege der Visualisierung erlauben. Raus mit diesem ganzen Overhead zur Navigation. Stattdessen würde vielleicht eine Customized Search Sinn machen.

Die richtige Frage

Interessant: Hier, in der Session von Moritz Stefaner, werden Visualisierung nicht als Tool zur Überprüfung von Hypothesen, sondern als Tools zur Generierung von Hypothesen gesehen. Ich habe oft den Eindruck - gerade auch im Vergleich mit Manuel Lima - dass solche Fragestellungen auf dieser VizThink-Konferenz oft noch nicht beantwortet werden. Eigentlich noch nicht einmal gestellt werden. Ich erinnere nur an die Session gestern (und den Post dazu): Dabei kam aus dem Auditorium die Frage, wie man Visualisierungen für unterschiedliche Stakeholder produzieren kann und wie man vor allem entscheiden kann, welche Visualisierung für welche Stakeholder passend ist.

Marketing-Maschine

Die Marketing-Maschine auf der VizThink schlägt voll zu - selten habe ich eine Veranstaltun erlebt, in der Sessions so unverholen zum Marketing missbraucht werden oder von den Teilnehmern als solches wahrgenommen werden.

Egal, ob es die Aufforderung ist, das "Was ist die visual thinking Industrie"-Poster zu vervollständigen oder die Pro-/Con-Liste für visuelle Kooperationssoftware (natürlich mit der visuellen Kooperationssoftware) zu erstellen - natürlich lernt man dabei was.

Montag, 13. Oktober 2008

Visual Thinking or Visual Explaining

Aus meiner ersten Session heute morgen habe ich ja die Frage mitgenommen, ob es einen Unterschied zwischen visual thinking und visual explaining gibt. Denn die Werkzeuge sind ja durchaus unterschiedliche - von Mind Mapping und ähnlichen brainstorming Techniken über mehrere Stufen hin zu dem Ergebnis, der Infographik, die den Kern der Nachricht transportiert. Dabei sind auch die Ziele durchaus unterschiedlich.

In den verschiedenen Sessions kommt es daher auch immer zu der Diskussion um Expertise-Modellen, d.h. die Schritte zwischen Daten und Wissen, Lernen und Lehren oder wie auch immer man die Skala aufspannt.

Auch für meine Arbeit - die Analyse und das Kommunizieren der Ergebnisse - ist diese Unterscheidung wichtig und sollte in der Software noch wesentlich stärker berücksichtigt werden.

Mini-Erkenntniss

Beim Mittagessen hab ich erfahren, dass es Leute gibt, die davon leben, bei Workshops live die Diskussionen in Flipchart-Bilder zu fassen. Eigentlich kam ich darauf, weil eines der Flipcharts aus einem Workshop wirklich herausstechend besser aussah als die anderen.

InfoViz'08 in Berlin

Moin,

heute bin ich auf der VizThink '08 Europe in Berlin. Worum geht's? "It's about spending lots of money on a poster a six-year old could draw". Nein, natürlich nicht - aber das ist das Vorurteil, mit dem diese noch relativ junge "Industrie" häufig konfrontiert wird.

Warum bin ich hier? Ganz einfach - Software ist meistens visuell. Das User Interface wird in der Regel visuell wahrgenommen, die Informationen visuell präsentiert und das sind meistens mehr als man nach der 5 +/- 2 - Regel im Arbeitsspeicher des Hirns halten kann.

Interessanterweise ist die Konferenz gar nicht so "visuell" wie man vielleicht vorher hätte vermuten können, sondern zum Teil auch sehr physisch aktiv: Es wird auch gerne Text auf Post-Its an die Wand geklebt. Aber eben Text. Ist das jetzt visuell? Weil's hinterher an der Wand klebt?

Die Mischung aus Designern, Software-Entwicklern, Consultants und zwischen den verschiedensten fachlichen Disziplinen hier ist ziemlich groß im Vergleich zu anderen Sachen, die man sonst so hört oder sieht. Deswegen ergeben sich auch in den kleinen Gesprächen am Rande der Konferenz sehr interessante Gespräche.

Dass visual thinking noch relativ jung ist und es eben nicht immer fest gefertigte Antworten gibt, sieht man auch daran, dass stärker als bei anderen Konferenzen die Fragen und Diskussionsbeiträge sehr interessante Einsichten bringen.

Ich bin gespannt, was noch an Einsichten kommt.

Dienstag, 22. April 2008

jax08: Advanced GlassFish

So, das ist jetzt hoffentlich spannender und die ersten paar Minuten kann ich doch ganz bestimmt auf der CD-Rom noch checken. Auf jeden Fall habe ich gerade den Talk gewechselt und lass mich mal zum GlassFish informieren.

Ein interessanter Link ist VisualVM, ein Monitoring Tool aktuell in Beta 2.

GlassFish unterstützt Single Sign On (SSO) für alle Web Applikationen bzw. mit OpenSSO gibt es auch ein CrossServer bzw. CrossDomain SSO. Interessant ist, dass OpenSSO auch heterogene Umgebungen abdeckt, indem man Adapter in die jeweiligen Umgebungen deployt. Jetzt gibt's einige Beispiele dafür, wie man mit OpenSSO in verschiedenen Setups nutzt. Jetzt gerade gibt's hier das Beispiel für die Nutzung in WebServices. Da SSO ja ein immer wiederkehrendes Thema ist.

Weg vom SSO-Thema, hin zu einem neuen Hype: Scripting. Man merkt schon, Daniel Adelhardt hat so gewisse Vorbehalte: "muss man zugestehen" und "Quick, Dirty & Good Enough Architekturen" - ehrlich, das was hier offensichtlich als "Enterprise Architekturen" firmiert ist halt nicht pragmatisch. Nicht in dynamischen Sprachen und nicht in Java.

Immerhin, Sun hat das erkannt und setzt auf JRuby. Jython ist auch dazugekommen. Jetzt fehlt nur noch offizieller Support für Groovy. Und Daniel Adelhardt gibt das Statement, dass Groovy in Netbeans und in GlassFish unterstützt wird. Ich persönlich bin ja überzeugt davon, dass dynamische Sprachen - hier unterscheide ich für mich ja von "Skriptsprachen" - auch im Enterprise Umfeld wesentliche Benefits bringen können.

Dass es Sinn macht, AppServer und "Skriptsprachen" zu kombinieren, stellt auch Daniel Adelhardt dar, sei es aus Security Gründen, aus Gründen der Betriebs-Infrastruktur und des entsprechenden KnowHows.

Schön ist die Unterstützung von PHP über das Quercus Servlet. Das gefällt mir. Auch für JRuby gibt es Bundle, das sich direkt in den GlassFish 2 installieren lässt. Von GlassFish 3 gibt es eine Mini-Version (geht quasi zurück auf die Keynote), die dann auch quasi "nur" den Ruby-Server bereitstellt.

Was passiert mit Groovy bzw. Grails? Interessanterweise wird das in Deutschland gemacht und ist aktuell in Arbeit.

Nächstes Thema: Rich Application Clients: Load Balancing und Failover for IIOP(s). Man kann da den Client mit dem ear bundlen und der Glassfish generiert dann automatisch ein JNLP File. Scheint aber alles nicht so einfach zu sein. Das ganze gibt's zum Nachlesen auf den Slides. Und hah - für Firewall/Loadbalancing-Szenarien gibt's 'ne Lösung.

Comet ist eine Lösung, um einen Push vom Server auf den Client auszulösen. Muss man sich mal genauer ansehen. Auf jeden Fall unterstützt der GlassFish Comet und man muss einfach im http-listener das Property "cometSupport" auf "true" setzen. Im Server-Log sollte dann so was stehen wie "Enabling Grizzly ARP Comet support". Die Basis für Comet im GlassFish ist die NIO, die ein non-blocking handling erlaubt. Im Service einfach den CometHandler implementieren und den CometHandler beim Request anhängen. Der Code ging auf zwei Slides und der Mechanismus ist ziemlich interessant.

Mein Fazit zu dieser Session: Ja, das mit OpenSSO hat nicht wirklich zwingend was mit GlassFish zu tun, aber dennoch war der Talk sehr interessant, hat eine weite Thematik behandelt und war absolut empfehlenswert. Gut, das Thema Comet hatten wir so auch schon mal, ohne zu wissen, dass es Comet gibt.

jax08: Presenter First for RCP applications using Spring OSGi

Wow, drei Buzzwords auf einmal im Titel, wenn ich dann auch noch testable dazunehme... also abwarten, ob das Buzzword-Bingo wird oder interessant. In diesem Zeitslot ist die Konkurrenz groß, ich habe auf Glassfish, Sprachtrends und Pragmatic Architecture verzichtet.

Natürlich wollen wir möglichst einfach, agil, testbar auch unseren Eclipse RCP UI-Code entwickeln. Also los. Kurze Einführung ins Beispiel, Test Cases für das Beispiel. Schade, da macht Heiko Seeberger schon zuerst die Tests, doch dann macht er (auf seinen Folien) wieder den "Fehler", sich nicht von den Tests leiten zu lassen. Er macht erst mal ein "so macht man's nicht"-Beispiel und hackt das Beispiel komplett in einem Composite. Naja, kein Wunder, dass sich das nicht testen lässt. Weiter. Nächster Punkt.

Ich denke, dass ich hier falsch bin - und mir den Vortrag lieber auf CD-Rom ansehe. Mal sehen, ich geh mal weiter in den nächsten Vortrag, wo es sich vielleicht nicht so leicht nachlesen lässt.

Grails - der Gral der Webentwicklung

Mann, oh mann! Zweimal schon wollte ich mir diesen Talk in Hamburg schon anhören - in der XP-User Group und an der HAW. Hat beide Male nicht geklappt, also muss es hier endlich gehen. Ich komme ja aus der Ecke Web-Entwicklung und das Thema wird mich bestimmt auch nicht ganz loslassen, auch wenn ich im Moment eher Service-orientiert und Eclipse RCP-lastig unterwegs bin. Vielleicht gibt's ja auch neue Ideen für ein RCP-Grail, denn convention over configuration hat sich dort auch noch nicht durchgesetzt. Hinzu kommt, dass dies die meiner Meinung nach "schwächste" Session-Runde ist (hier hatte ich nur vier Talks zur Auswahl) und wir uns kollegentechnisch etwas aufgeteilt haben und wir so nichts relevantes verpassen. Hoffentlich.

Hey, cool. Endlich hat sich's mal gelohnt, dass mein Notebook so 'nen schwachen Akku hat: Dadurch wollte ich mir einen Platz mit Steckdose sichern, war früher da und muss jetzt wenigstens weder stehen noch am Boden sitzen. Grails ist ein Thema, das brennt.

Der Vortragsstil - zumindest der Einstieg - ist schon mal klasse. Ich persönlich stehe ja auf diese Art von Vorträgen. Anhand von "Praxisbeispielen" beleuchten die beiden Web-Frameworks: Es ist mehr eine Pannenshow in Bildern aus allen möglichen Bereichen, mit Übertragung auf die Web-Frameworks. Die Folien danach sind eher klassisch, aber gut, es soll ja auch nicht nur cool sein, sondern auch informativ.

Spring, Hibernate und Sitemesh sind die Grundlagen von Grails, Groovy ist nur der Zuckerguß auf diesen Grundlagen. Und da der Zuckerguß dünn ist, wird die Applikation auch nicht dick, soll heißen langsam durch die doch vergleichsweise geringe Performance. Neben diesen Grundlagen stecken in Grails noch andere Libraries für Ajax, Batch, Sicherheit und Tests. Eigentlich sind es die alten Bekannten aus der Welt der Webentwicklung.

Jetzt kommt ein Crash-Kurs Groovy, den gebe ich hier mal nicht weiter. Für Java-Entwickler ist der Einstieg ja suuper-leicht, aber wie immer dauert es natürlich eine Weile, bis man wirklich in der Denke der Sprache angekommen ist. Ich reite noch mal drauf rum - wer LISP kann, ... naja, lassen wir das. Worauf auch Stefan Roock nochmal hinweist: Groovy und Java integrieren sich nahtlos, man kann von Java-Klassen auf Groovy-Klassen zugreifen und umgekehrt.

Jetzt zu Grails: Zunächst mal die Persistenz: Domain-Objects werden automatisch gemappt. Ich muss also keine Hibernate-Konfiguration, keine JPA-Annotationen oder sonst etwas machen, es geht sofort los. Wobei man zugeben muss, dann man es hier halt nicht über Annotationen oder sonst etwas machen muss, sondern über die Konvention, dass es in einem Package domain liegt und dass man die Felder hasMany oder belongsTo benutzt, die jeweils eine Map bekommen. Constraints werden beispielsweise über eine Closure definiert, die eine DSL enthält. Spannendes Konzept. Stefan Roock weist noch darauf hin, dass man sich leichter tut, wenn man es erst mal so hinnimmt und nicht versucht, es erst mal zu verstehen und dann zu machen. Stimmt wohl, das Konzept ist einfach zu benutzen. Wie die Abbildung auf die Datenbank-Constraints passiert muss man eigentlich gar nicht wissen. Aber es zeigt schön die Groovy-Denke.

Der DynamicFinder ist total interessant, da er wundervoll die Dynamik der Sprache zeigt: Adresse.findAllByPostleitzahlAndGueltigBis(21502, null). Ein MOP (Metaobject Protocol) hat echte Vorteile! Die Zwischenfrage nach der IDE-Unterstützung ist natürlich interessant: IDEA hat die beste Unterstützung, Eclipse und Netbeans ziehen da nach.

GroovyServerPages setzen voll auf Sitemesh und entsprechende Taglibs. Das kann man in Java natürlich so auch selbst machen, aber Grails bringt das halt schon alles mit.

Wir haben Model und View, die Controller verbinden das. Dabei werden Controller in einem eigenen Package und über das Suffix Controller identifiziert. Interessanterweise werden die einzelnen Aktionen nicht als Methoden realisiert, sondern als Closures, die in Feldern gespeichert werden.

Jetzt geht's schon ins Eingemachte: AJAX ist eingebaut (Prototype / Script.acoluo.us, Yahoo! UI als Plugin, Dojo als Plugin). TagLibs lassen sich einfach selbst bauen: Wieder per Konvention in den Ordner taglib die eigene TagLib reinwerfen und schon ist die Taglib fertig. Stefan Roock weist darauf hin, dass man durch die Einfachheit in Grails-Projekten eigene Taglibs viel häufiger einsetzt als in Java-Projekten. Glaube ich sofort.

Testen ist in Grails direkt eingebunden. Es generiert Skelette für Domain-Klassen und Controller, integriert die Ausführung von Tests in die bereitgestellten Skripte etc. Noch ist das ziemlich langsam, weil die VM, das Framework und der Webserver immer mal wieder hoch- und runtergefahren wird.

Jetzt kommt Stefan Roock schon zu RESTful Services mit Grails, sehr interessant, aber doch durchaus vielleicht schon fast zu tief. Die Zuhörer schwitzen zum Teil schon.

Aber, es ist fast geschafft. Jetzt geht's (nach der unvermeidlichen Werbeeinblendung) zur Live-Demo. Also Console auf, TextMate auf und los geht's. Bernd Schiffer baut sich erst mal eine neue Grails-Applikation. Beziehungsweise er lässt sich eine neue Applikation bauen, und zwar vom entsprechenden Grails-Skript.
Die Domain-Klasse wird wieder per Skript erzeugt. Erst mal ist das nicht spannend, aber Plugins für Grails können sich hier einklinken und so wird beispielsweise zu der Domain-Klasse auch eine Test-Klasse erzeugt.

Jetzt kann man die Applikation starten (dazu fährt intern ein Jetty hoch). Noch passiert nicht viel - die Applikation fährt hoch, aber es ist nur die Grails-Standard-Seite zu sehen. Also - Server läuft weiter - macht Bernd Schiffer sich einen entsprechenden Controller. Den sieht man jetzt schon auf der Einstiegsseite. Fehlt noch ein View, aber die entsprechenden Ordner sind auch schon angelegt. Also flugs eine gsp-Seite angelegt.

Bisher alles ohne Server-Neustart zu sehen.

In der Klasse BootStrap gibt's eine init (und eine destroy)-Methode, dort kommt noch ein bisschen Init-Code hin (Domänen-Objekt erzeugen), Server stoppen und starten (sonst wird die BootStrap-init-Methode nicht ausgeführt). Und schon sieht man was.

Jetzt geht's weiter über das Einfügen von Links, mehr Code im Controller etc. Damit sind wir durch. Die Fragen gehen im Rauschen unter, über DataSources kann die zugrundeliegende Datenbank auswählen, Refactorings sind noch nicht wirklich gut unterstützt, es gibt verschiedene Möglichkeiten, (Java) Legacy-Code zu integrieren. Mit DB-Migrate kann man die Migration von Datenbank-Schemata durchführen.

Noch mein Fazit: Der Talk war eine gute Einführung mit einer schönen Mischung aus theoretischer Einsicht und einem praktischen Teil. Groovy ist auf jeden Fall einen Blick wert. Wann kommt jetzt das Buch?

Randnotiz Treffer

Gerade auf der JAX-Website gelesen, dass es "Beste Gelegenheiten für Networking & Erfahrungsaustausch!" gibt. Stimmt, bin gerade kurz nach seinem Vortrag in Stefan Zörner reingelaufen. Mal sehen, was mein Kollege nachher über Zörners Talk erzählt.

Spring: Vom Framework zum Ökosystem

Ich habe mich für die Session "Spring: Vom Framework zum Ökosystem entschieden". Damit hat Eberhard Wolff gewonnen vor Rod Johnson mit seiner Q&A-Session zur Keynote und ein paar anderen interessanten Sessions. Hoffentlich wird's so interessant wie ich mir das gerade erhoffe. Natürlich stellt sich gerade in dieser Session die Frage, ob Spring mit allem nicht mittlerweile zu groß wird und damit in die Falle tappt, in der Java EE jetzt schon steckt.

Wow, erst mal schmeißt Wolff viiiiele Blasen an die Wand: Die ganzen Spring-Teilprojekte. Eine der Blasen ist Spring Batch. Spring Batch ist die Unterstützung von Batch-Jobs für Java, und dass Batch Jobs in vielen Projekten wichtig sind. Typische Probleme von Batches (ich denke mal, die Unterstützung dafür kommt gleich) sind Wiederaufsetzen nach einem Fehler, Parallelisierung und die Optimierung von Datenbank-Operationen.

[...] (Anmerkung: Hier redet Eberhard Wolff ziemlich detailliert über Spring Batch) Und weiter, und mehr, und noch mehr Batch Details. Ja, ich weiß was ein Batch ist und wie man so was bauen würde. Die Details von Spring Batch kann ich mir anschauen, jetzt wo ich weiß, dass es das gibt. Ich fange gerade an, in meinen Unterlagen zu blättern und nach Alternativen zu suchen. Das ist nicht der Vortrag des Titels, sondern irgendwas anderes. Das ganze geht mir persönlich viel zu tief in Spring Batches, ein deutlich flacherer Überblick hätte mir hier definitiv gereicht. Mehr, unterschiedlicher. Was gibt es noch an Blasen.

Endlich geht's weiter zum nächsten Bubble: Spring Integration. Das löst typische EAI-Probleme, also Messages, Routing, Splitting, Transformation etc. Das Framework basiert auf einem Pipes & Filters Pattern und ist Event-driven. Das heißt, dass sich das Framework um das Message-Listening kümmert und dann die Service-Aufrufe regelt. Beispielsweise übernimmt das Spring Integration Framework das Thread-handling. Super, das ist jetzt mal auf dem korrekten Niveau. Jetzt nur nicht zu sehr abgleiten ins Detail. Wir gehen jetzt mal in den Code, es könnte schon zu detailliert werden. Jaaa, es wird zu detailliert. Gut, es interessiert mich auch, ich raschle nicht, aber es ist eigentlich zu detailliert. Ich tackere das jetzt nicht mit, sondern verweise einfach mal auf die entsprechenden Slides. Ich hoffe mal, dass ich die CD-ROM mit den Slides nachträglich bekomme. Kommt das Ding per Post oder muss man es holen? Worauf ich hier noch hinweisen möchte: Spring Integration hat eine klassische Java-API, man kann aber auch sehr gut und einfach mit Annotations arbeiten.

Spring Web Services ist das nächste Bubble, das Eberhard Wolff vorstellt. Interoperabilität ist das Ziel von Web Services und Contract First ist das Mittel zum Zweck. Wenn man schon mal WebServices hat, dann kann man mehr machen als nur request-response und man möchte ggf. auch direkt auf das XML durchgreifen können.

ContractFirst ist gesetzt, wie soll man sonst Interoperabilität gewährleisten. Eine WSDL von Hand schreiben macht keinen Spaß. Umgekehrt ist der Weg der Generierung der WSDL aus Java auch suboptimal - es ist contract last, die Java Klassen entsprechen nicht den WSDL/XSD-Möglichkeiten, man bindet sich ggf. an die einzelnen WebService-Stacks. Selbst schon erlebt - WebServices sind per se erst mal nicht wirklich interoperabel zwischen verschiedenen Stacks und Sprachen. Jetzt kommen wir wieder zu dem Punkt, dass die WSDL eigentlich nicht en bloc von Hand geschrieben werden sollte, sondern aus verschiedenen Artefakten zusammengeneriert werden sollte.

Spring verwendet ein XML Schema zur Definition der Datenbeschreibung und der Methoden. Die Komplexität des SOAP Stacks (Endpoints, Ports und so weiter und so fort) kann man dann an anderer Stelle machen.

Für das Mapping von Objekten auf XML und umgekehrt kann man die vorhandenen Techniken nehmen - JAXB 1 und 2, Castor, XMLBeans, JiBX, XStream oder was auch immer. Oder man mappt nicht, sondern geht direkt auf die XML-Struktur runter, beispielsweise mit JDOM oder SAX. Die dritte Alternative geht über Annotationen und XPath. Das sieht interessant aus.

In 1.5 ("was wir jetzt gerade shippen") gibt es neu auch JMS und Email Transport.

Weitere Bubbles werden noch nicht mal kurz vorgestellt, da es z.T. noch eigene Talks dafür gibt.

Spring Enterprise bundled verschiedene Dinge zusammen: Zum Beispiel das Advanced Pack for Oracle, die bestimmte Misfeatures des Oracle RAC "ausbügelt". Es gehört auch die SpringSource Tool Suite dazu und die SpringSource Application Management Suite.

Ok, wir haben gesehen, dass Spring mittlerweile auch ein ganzer Zoo von Frameworks ist, aber diese einzelnen Frameworks sind wesentlich loser aneinander gekoppelt als dies bei JEE der Fall ist.

Future of Java

In der Keynote erzählt Rod Johnson was über die Zukunft von Enterprise Java. In seiner typisch amerikanischen Art führt er erst mal aus, dass Java nicht mehr sexy ist: "No one will date a Java developer". Ruby sei doch so viel sexier für Web development. Ist natürlich nicht so, sonst stände Johnson ja nicht hier, sondern würde Ruby machen. Also, noch viel amerikanischer: Wir ziehen erst mal Statistiken raus - indeed.com job trends gibt ja die nötigen Daten ohne große Arbeit. Also der Vergleich mit Ruby, mit dot.net, alles in bunten Bildern. Fazit: Damit Java-Entwickler weiter gedated werden, muss sich Java ändern. Mal schauen, was Johnson als six plus two predictions präsentiert.

Aber zuerst mal zu den Faktoren, die Änderungen notwendig machen: Zuerst mal ist da die "productivity challenge" - dass man mit Ruby on Rails schneller ist in der Entwicklung von bestimmten Web-Applikationen ist als mit Java hat sich nun schon rumgesprochen. Der Punkt daran ist, dass die Java community an den "low hanging fruits" vorbeispringt. Warum also immer Rakentenphysik, wenn's auch einfach geht. Si!

Der zweite Grund für notwendige Änderungen ist einfach das Alter von Java EE. Java ist einfach nicht mehr schlank, weil sich mittlerweile eine Menge "baggage" angesammelt hat. Gut, ich hätte zwar "garbage" genommen, aber der Effekt ist der gleiche: Man muss das System wieder aufräumen, den Frühjahrsputz machen. Johnson sieht in Java EE 6 genau den Versuch, die Java Plattform auf Vordermann zu bringen. Die beiden Idees hinter Java EE 6 sind Extensibility und Profiles (steht auch im JSR-316). Die Grundlage für die Extensibility ist die Erkenntnis, das man nicht alles in die Plattform stecken muss, sondern dass die Plattform wirklich, ja was, eine Plattform für andere Frameworks sein sollte. Immerhin, die Erkenntnis ist für die Java EE Plattform wirklich neu. Klingt aber gut, denn mir geht das, beispielsweise mit den Appservern als Ergebnis von Java EE, oft so, dass ich viele der angebotenen Dienste nicht brauche. Andere auch nicht, und das ist wohl der Grund, warum der Tomcat als "App-Server light" so beliebt ist. Sorry, ich bin abgeschweift.

Johnson ist mittlerweile schon bei den Profiles. Es wird erst mal drei davon geben und sie sind Ausprägungen der Plattform. Die einfachste Variante "Profile A" (ich denke mal, dass sich der Name noch ändern wird) ist im wesentlichen der Tomcat: Servlets, JSPs, EL und JSTL und solche Sachen. Wichtig sind dabei Änderungen in der Sichtweise: Die Extensibility schlägt wieder zu und so muss man z.B. nicht immer alles von Hand in die web.xml eintragen. Stattdessen wird es eine API dafür geben, so dass Frameworks einfacher auf der Java EE (light) Plattform aufsetzen können.

Profile B ist Profile A plus persistence und zwei Komponenten-Modelle (mit Fragezeichen). Eventuell wird es ein EJB 3.1 light geben, was auch immer das sein wird. Das zweite wird evtl. ein Web Beans Modell sein (JSR-299). Profile C wird ziemlich genau das sein, was wir jetzt schon als Java EE haben. Rod Johnson hat jetzt schon auf den Folien stehen, dass das volle Java EE wenig Relevanz hat.

Für Sun ist das natürlich eine gute Strategie: Mit dieser Strategie kann sich Java vielleicht noch ein paar Jahre unten gegen Ruby und oben gegen Dot.Net verteidigen. Ob es für Entwickler wirklich einen echten Effekt zeigt, wird sich noch zeigen: WebLogic, WebSphere und JBoss werden natürlich ihre Produktstrategie ein Stück weit unabhängig von Sun überdenken. Die Tendenzen dort gehen ja eher dahin, immer mehr in die Produkte zu packen - und sei es nur als Marketing Fake. Aber das ist ein anderes Thema. Rod Johnson kommt zu ähnlichen Schlüssen auf seiner nächsten Folie. Interessant, die nächste Statistik kommt auch (siehe oben) - Tomcat ist die am häufigsten eingesetzte Plattform für Enterprise Java. Was Sun hier also als Strategie fährt ist einfach ihre Anpassung an die Realität. An die Realität, die wir hier im Auditorium schon alle leben.

Jetzt zu den lange angekündigten Predictions:
"Real competition will return to the application server market", jaja, Tomcat kann sich dann auch den Java EE-Stempel aufkleben und damit hat man einen weiteren Marktteilnehmer. Und neben Tomcat noch viele andere. Damit gibt es eben eine niedriger Markteintrittsschwelle. Ok, im wesentlichen hatte ich den Punkt ja oben auch schon, denn der Punkt ist doch, dass die vollen Java EE Appserver Funktionalität realisieren, die nur die wenigsten nutzen. Geht mir im übrigen auch so - im letzten Projekt hatten wir einen WebLogic, benutzt davon haben wir die Servlet Engine für die WebServices und JMS. Das hätten wir auch mit dem Tomcat machen können.

Prediction 2: "Tomorrow's application server will be lightweight and modular". Die JBoss-Leute schreien jetzt "haben wir schon, haben wir schon". Richtig. Und alle anderen werden laut Johnson auf OSGi als technische Basis setzen.

Prediction 3: "Tommorow's application server will not merely implement JCP specifications". Komisch - das tun sie doch heute schon nicht. Und wenn, dann pushen sie ihre originären Sachen als neue Standard-Vorschläge. Aber Johnson führt das noch ein bisschen aus: Es wird nicht nur JCP standards geben, sondern z.B. auch die von der OSGi Allience. Viel interessanter ist der Umkehrschluss, in dem Rod Johnson ausführt, dass der JCP nicht immer das Rad neu erfinden muss. Wer braucht commons logging, wenn es schon log4j gibt. Wer braucht ein neues EJB-Konzept, wenn es Spring gibt. JSR 277, wenn es OSGi gibt. Ob sich diese Einstellung endlich durchsetzen kann? Ich bin kein Fan davon, dass es nur (Gedanken-) Monopole gibt und wer eine bessere Idee hat, der sollte sie auch in Code umsetzen. Aber oft ist es eben keine bessere Idee, manchmal noch nicht mal eine andere. Eben nur eine andere Organisation - das not invented here Phänonomen macht auch vor dem JCP nicht halt. Damit kommt auch die extended prediction: the JCP will run on open source.

Prediction 4: The market will address the gap between Tomcat and WebLogic/WebSphere. Das stimmt, denn das stimmt ja auch jetzt schon. Nur dass sich zum Teil jeder seine eigene Lösung strickt. Man kann auch einen Tomcat so produktiv einsetzen wie den WebLogic.

Prediction 5: The gap between application servers and ESBs will be bridget. Naja, das ist noch ein langer Weg. Es ist zum Beispiel immer noch ein weiter Weg dahin, dass meine Plattform entscheidet, ob es jetzt aus Lastgründen einen lokal deployten Service nutzt oder den gleichen Service auf einer anderen Maschine. Aber solche Features wären für mich ein echter Fortschritt auch für den SOA-Gedanken. Und auf den SOA-Gedanken kommt Rod Johnson auch gerade, klar, der liegt bei dem Thema ja nahe und das Buzzword trägt immer noch.

Prediction 6: The Black knight will be defeated. Oder anders ausgedrückt: EJB ist dying. Jaja, das ist keine Prediction, das ist eine Beobachtung. Wer macht schon EJB, wenn er stattdessen Spring machen kann. Interessante Statistik wieder - in den USA sieht man das mit EJB offensichtlich (noch) etwas anders. Aber - die erste witzige Statistik - die Kurven für die Entwicklung von Java EE und Cobol gleichen sich wie ein Ei dem anderen. Beides Legacy-Techniken.

In der Conclusion gesteht Johnson ein, dass Java EE 6 die Relevanz von Java EE erhöht, aber dass Java nicht mehr die Zukunft bestimmen wird.

Auf zur nächsten Session.

JAX Eröffnung

Tag 1 der JAX 08. Gestern war ich ja schon auf Tag 0, dem Agile Day vor der JAX. Sebastien Meyen -Chefredakteur bei S&S Media, dem Host der JAX - sagt es gerade, es waren ca. 400 Leute da. Jetzt erzählt er erst mal was über den aktuellen Kontext - welche Themen sind interessant (Architekturen, Agilität, Techniken), in welchem Marktumfeld sind wir hier alle unterwegs: Java EE, EJB 3, Alternative Stacks, Vom Web 2.0 zum Enterprise 2.0 und dynamische Sprachen und Scripting.

Sebastian Meyen geht gerade bei den dynamischen Sprachen vor allem auf Groovy ein. Ich persönlich finde das ja sehr nett, denn ich halte - auf der Java Plattform, die ja sehr gelungen ist - Groovy für die bessere Wahl als beispielsweise JRuby. Gut, aber das ist vermutlich der nächste Glaubenskrieg. Zusammengesetzt sieht Meyen folgenden Stack: Unten Java EE & Co., darüber eine "dynamischer" Layer von dynamischen Sprachen oder Rule Engines und darüber noch eine weitere Schicht von domain-specific languages.

Für das Eclipse Forum gibt's noch den Hinweis auf die Opening Session, in der auch der Weg zu Eclipse 4.0 dargestellt wird. Vielleicht sollte ich da noch hingehen? Ich kann mich doch nicht zerreißen.

Hey, interessante Frage von der Bühne: Wer war eigentlich letztes Jahr schon auf der JAX? Ich würde mal schätzen, dass sich so ungefähr ein Fünftel meldet. Und wer war vor zwei Jahren schon da? Überraschung: Die gleichen Leute. Mal sehen, ob ich nächstes Jahr eine von den beiden Fragen mit ja beantworten kann...


Gäääähn, jetzt werden die ganzen "großen und wichtigen Namen" genannt. Lesen kann ich selbst, steht doch alles im Programm. Schade, bis gerade war die Eröffnung doch ganz nett gemacht. Naja, gehört halt dazu...