As mentioned before, we are currently working on a new marketing strategy for LinuxTag, not only for 2009 but far beyond, defining a solid groundwork for the strategic definition of the LinuxTag brand. This includes tangible marketing ressources such as templates, colors, fonts and all that is needed for a full corporate design but also an effective definition of what LinuxTag is - what LinuxTag stands for and - finally - why people attend LinuxTag. We need this to improve our strengths and work on our weaknesses.
One key momentum that we thought about was "what are the motivations that brings people to LinuxTag?". What does the common visitor expect when attending the show? We isolated three main points on this:
Networking A lot of people attend LinuxTag to see all those guys from the FOSS world that they see frequently at events like this. To get in touch, to work together in person is an important aspect of LinuxTag. Each year, we have requests for rooms from development teams where they can gather to discuss topics they can't properly address by e-mail. It is not uncommon that these people meet up for the first time in real life on LinuxTag. On the other side, many people come to the show to improve their business network. I do not exaggerate by arguing that LinuxTag is the
Knowledge We know from our yearly surveys that many people come to LinuxTag to hear conference talks. There was a time we underestimated the marketing value of the conference, but this was plain wrong: the conference is the main attraction of LinuxTag. All other parts are there only to support the conference, plain and simple. We want to provide world class know-how presented by world class speakers each and every year. This is the key point of the whole LinuxTag endeavour.
Lifestyle LinuxTag is part of the FOSS community. The geekdom is becoming more and more sexy and more and more people want to be part of it. LinuxTag brings this unique feeling that no other conference has. Try to get that fine sense of completeness, of technology insight paired with the deep friendlyness of the Open Source principle on your common IBM marketing sell-me-your-stuff event. And there is more: be part of it! Nowhere else it is so easy to talk to the FOSS people and contributing to the pool of ideas, concepts and - finally - software. Be there and be part of it! And, if you're out on your business, there is no place like LinuxTag to find excellent staff for your technology venture because these people are attracted by the unique lifestyle LinuxTag has to offer. If you really want to find the knowers, be at LinuxTag.
So we have these three key spots of motivation that drives LinuxTag. We now have to package them into a concise marketing message, transform it to a nice presentation and there we go..
Harry Potter and the Order of the Phoenix movie Gerade auf meinem Schreibtisch gelandet: die 11er-Ausgabe der Linux-User, die am Donnerstag erscheint. Darin ist der zweite Teil meines Mediacenter-Artikels enthalten. Beschrieben wird, wie man aufbauend auf der Linux-Installation MMS als Multimedia-Applikation und VDR als Videorekorder mit DVB-T nutzt.
Marko hatte mich vor einiger Zeit schonmal auf Elisa aufmerksam gemacht. Sieht sehr vielversprechend aus und könnte eine echte Alternative zum doch recht spröden MMS sein. Das wird mein nächstes Wochenendprojekt...prinzipiell sollte aber auf der S100 auch XBMC laufen, schließlich hat die XBox 1 auch nur 64 MB RAM. Dazu müsste aber auf der S100 zunächst mal zwingend OpenGL funktionieren - und zwar über den TV-Out...und da bin ich im Moment etwas skeptisch.
Achso: mein Artikel "10 Gebote für erfolgreiches BPM" aus der Computerwoche gibts jetzt auch als offizielles PDF zum herunterladen.
So, heute mal wieder ein Artikel aus dem tiefen Tal der lustigen Softwarefrickeleien. Ich habe mich am Wochenende mal intensiv mit JEE, Eclipse und Maven und dem Zusammenspiel dieser Dinge auseinandergesetzt. Die nächste Version des LinuxTag eTicket-Systems soll voll auf JEE setzen.
Maven mit Eclipse für JEE-Projekte zusammenzubringen ist nicht so ganz einfach. Deswegen hier eine kleine How-To.
Seltsamerweise existieren im Netz keine wirklich verwendbaren "Kochrezepte" dafür, obwohl es sich aus meiner Sicht um ein "Standardproblem" handelt.
Ziel ist es, die Vorzüge von Eclipse bei der Entwicklung von JEE-Modulen zu nutzen (Hotdeployment, Servermanagement, Debugging usw.) und gleichzeitig die volle Buildfähigkeit über Maven zu erhalten.
Dazu muss man grundlegend einen anderen Weg gehen, als das bei JSE-Projekten der Fall ist: statt ein Projekt zunächst auf der Maven-Ebene aufzubauen und dann von Maven die Eclipse-Settings über "mvn eclipse:eclipse" erzeugen zu lassen, muss ein JEE-Projekt von Eclipse her aufgebaut werden. Maven ist deutlich flexibler anpassbar als die JEE-Eclipse-Plugins.
Schritt 1: Eclipse JEE-Projekte anlegen
Über die ganz normalen Wizards wird ein JEE-Projekt mit allen Untermodulen angelegt. Für das Beispiel gehe ich von folgenden einzelnen Eclipse-Projekten aus:
Projekt, das die EJBs enthält. Hier werden (abweichend vom Eclipse-Standard) später auch die Domain-Klassen und die Remote-Stubs der EJB abgelegt. Maven erzeugt beim Releasebuild automatisch ein abgespecktes Client-JAR, dass nur die vom Client benötigten Klassen enthält. Während des Eclipse-Workflows werden die Klassen dieses Moduls vollständig mit dem Client deployt, liegen also zweimal physikalisch auf dem Server, falls der Client eine JEE-Serveranwendung wie z.B. ein WAR ist. (einmal beim EJB, einmal beim Client). Das ist verschmerzbar, stört nicht und ist durch die Eclipse-Governance auch sicher konsistent.
DemoServlet Der Client für die EJBs in Form einer JEE-Weblayer-Anwendung. Hier sind Standard-Servlets und/oder JSPs enthalten, die über JNDI auf die EJBs zugreifen. Externe Clients sind ebenfalls möglich, aber der JEE-Client ist der in diesem Fall komplexere Fall, weil das WAR ebenfalls deployt werden muss.
DemoEAR Das umgebende EAR-Projekt, dass aus dem EJB und dem WAR des Clients ein deploybares EAR-Archiv erzeugt. Da Maven kein gemeinsames Artefakt- und POM-Multiprojekt erlaubt, ist das EAR-Projekt ebenfalls ein Maven-Subprojekt.
Beim Erstellen der Projekte muss auf die Projektabhängigkeit geachtet und ggf. angepasst werden. Eclipse geht im Standardfall davon aus, dass Domainklassen und Stub-Interfaces im Client angesiedelt sind. Maven erwartet diese Klassen aber im Serverprojekt und generiert lieber daraus ein getrenntes Client-JAR für den Client mit diesen Klassen. Aus meiner Sicht sauberer und Eclipse auch einfach beibringbar ist der Maven-Weg. Dazu müssen die Abhängigkeiten folgendermaßen eingestellt sein:
DemoEJB hat keine definierten Abhängigkeiten. Sind die Abhängigkeiten eingestellt müssen nun die Pfade "Maven-like" angepasst werden. Dazu müssen die Java-Sources von den restlichen Resources getrennt und im üblichen Verzeichnisschema angeordnet werden. Dies ist über die Projekt-Properties unter "Java Build Path -> Source" zu erledigen.
Mit der jetzt vorliegenden Einstellung kann dann ein Deployment-Server definiert werden und das Projekt über Eclipse normal genutzt werden. Hot-Deployment und Debugging funktioniert direkt aus Eclipse heraus.
Als nächstes müssen die Maven-Einstellungen hinzugefügt werden, damit das Gesamtprojekt per Maven bau- und deploybar wird.
Schritt 2: Maven-Konfiguration
Die Verzeichnisstruktur in Eclipse sieht im Moment folgendermaßen aus:
- workspace + DemoEAR + DemoEJB + DemoServlet
Für die Maven-Konfiguration legen wir ein Hüllprojekt um die drei Einzelprojekte. Dieses Hüllprojekt ist für Eclipse nicht notwendig und nur für die "Projektklammer" des Multi-Projekts für Maven nötig. Aus diesem Grund wird dieses Hüllprojekt am besten von Hand angelegt und über die Kommandozeilentools ins SVN eingecheckt.
Für die Entwicklung bedeutet das, dass das Arbeiten und Bauen mit Maven und Eclipse leicht unterschiedlich erfolgt. Die Zielverzeichnis bzw. Projektstruktur sieht so aus:
In Eclipse wird dann nicht das Hüllprojekt ausgecheckt und genutzt, sondern nur die drei Subprojekte. Die Einstellungen des Hüllprojekts sind nur für einen Maven-Build nötig. In diesem Fall wird das Gesamtprojekt ausgecheckt und per "mvn package" das resultierende EAR-Archiv im Subprojekt "DemoEAR" gebaut.
POM des Hüllprojekts
Die POM des Hüllprojekts ist recht simpel. Sie besteht aus einem einfachen Multi-POM mit zusätzlichen Repository-Einstellungen:
Das JBoss-Repository ist für die Abhängigkeiten zu den JEE-Bibliotheken nötig, die in den Subprojekten definiert sind. Das Projekt wird damit gegen die JEE-JBoss-Implementierung gebaut. Das bedeutet explizit nicht, dass die resultierenden JEE-Module nicht in anderen Appservern laufen, die Bibliotheken werden als "provided" dort vorausgesetzt und nicht mit gepackaged. JBoss bietet eine zertifizierte JEE 1.5-Implementierung. Trotzdem sollten wir uns dafür im nicht-JBoss-Fall noch ein paar Gedanken zur QS machen, das nur am Rande.
POM von DemoEJB
Das DemoEJB-Projekt ist ein einfaches Maven-Projekt, dass das EJB-Plugin verwendet, um ein EJB-Jar zu erstellen.
Falls weitere JEE-Abhängigkeiten benötigt werden, können diese hier hinzugefügt werden. Als Parent wird das Hüllprojekt angegeben. Die JBoss-Repository-Definitionen werden von dort geerbt.
Die "generateClient"-Einstellung sorgt dafür, dass ein zusätzliches "virtuelle" Artefakt erstellt und dem virtuellen Repository hinzugefügt wird. Auf dieses referenzieren wir dann später in den Abhängigkeiten des Clients. Dieses spezielle Client-JAR enthält nur die Entities und die Stubs. In der Konfiguration kann über weitere Parameter noch genauer angegeben werden, welche Bestandteile des EJB-Codes in den Client gepackaged werden. Genauere Infos dazu sind in der Plugin-Dokumentation zu finden.
POM des Clients
Das Client-Projekt "DemoServlet" ist ein Standard-WAR-Projekt, dass aber zusätzlich eine Abhängigkeit zur zuvor erstellen "virtuellen" Client-Bibliothek enthält:
Statt "ejb" wird "ejb-client" als Typ angegeben. Würde "ejb" angegeben, so würde der gesamte Code des EJB-Projektes im resultierenden WAR mitgepackaged werden.
POM des EAR-Projekts
Das EAR-Projekt baut aus den vorhandenen Artefakten das EAR zusammen und deployt es optional auch direkt in einem JBoss-Server. Das EAR-Projekt enthält selbst keinen Quellcode dafür aber die EAR-Deployment-Deskriptoren.
Problematisch ist die Einstellung des JBoss-Homedirs. Diese Einstellung ist im Moment leider nicht extern einstellbar. Allerdings ist die Nutzung des JBoss-Plugins nur nötig, wenn direkt aus Maven heraus deployt werden soll.
Bauen und Deployen
Damit ist die Konfiguration insgesamt fertig. Unter Eclipse lassen sich die Projekte normal mit den Eclipse-Bordmitteln nutzen. Will man einen Maven-Build vornehmen, so wird das Hüllprojekt ausgecheckt und mit "mvn package" das Projekt gebaut. Nach dem Vorgang liegt im EAR-Projekt das fertige EAR-Archiv.
angesehen: Wanted. Naja, was soll man sagen...wer auf anregende Dialoge, feinsinnige Handlung und eine intellektuelle Pointe steht, dem wird der Film nicht gefallen. Alle anderen lehnen sich zurück, schalten das Hirn aus und schauen einfach zu wie Actionsequenz auf Actionsequenz folgt, literweise Blut fließt und eine zweifelhafte Moral vermittelt wird.
Miss Jolie nimmt man dabei auch die harte Schlägerbraut nicht so richtig ab. Was in Tomb Raider noch ganz gut geklappt hat ist hier teilweise schon an der Grenze zur Lächerlichkeit. Angelina Jolie ist dermaßen dürr und sieht krank aus, dass man ihr am liebsten die ganze Zeit einen Schokoriegel reichen würde.
As mentioned before, we are currently working on a new marketing strategy for LinuxTag, not only for 2009 but far beyond, defining a solid groundwork for the strategic definition of the LinuxTag brand. This includes tangible marketing ressources such as templates, colors, fonts and all that is needed for a full corporate design but also an effective definition of what LinuxTag is - what LinuxTag stands for and - finally - why people attend LinuxTag. We need this to improve our strengths and work on our weaknesses.
Harry Potter and the Order of the Phoenix movie Gerade auf meinem Schreibtisch gelandet: die 11er-Ausgabe der Linux-User, die am Donnerstag erscheint. Darin ist der zweite Teil meines Mediacenter-Artikels enthalten. Beschrieben wird, wie man aufbauend auf der Linux-Installation MMS als Multimedia-Applikation und VDR als Videorekorder mit DVB-T nutzt.