Greetings from SHR

Nun also doch. Seit vorgestern bin ich glücklicher User von SHR-Unstable (Version vom 08.08.). Ich bin regelrecht begeistert, wie stabil und zuverlässig das System nach einigen Anpassungen läuft. Nur von opkg-cl upgrade sollte man die Finger lassen

Nach dem Einbinden der Jalimo-Repos installieren sich jetzt auch alle Java-VMs und die SWT- bzw. Java-DBus-Packages.

Wunderbar. Der Urlaub ist gerettet. Die Basteleien mögen beginnen

Java + DBus + OM2009 = Zicken ohne Ende

Die letzten Tage hatte ich etwas Zeit, mit Java und DBus auf meiner KDE-Kiste rumzuspielen. Da es jetzt unter Debian läuft, war mein nächster Versuch, es auf dem Neo Freerunner auszuprobieren. Da meine aktuelle OM2008.12-Distri leider noch nicht das DBus-basierte FSO-Framework verwendet, habe ich mir die Testing-Version von OM2009 auf die Speicherkarte installiert. Hier fängt auch schon die Leidensgeschichte an Nach einer halben Ewigkeit sieht man das sehr karge, eigentlich nur schwarz-weiße, User-Interface. Hier mal ein kleiner Screenshot:

Paroli Launcher

Mit Java siehts irgendwie düster aus. Es gibt zwar wieder die Standard-Packages in dem Testing-Repository, aber alles in Richtung DBus-Java, etc. fehlt. Hier kann man nur auf die Jalimo-Repositories ausweichen, welche aber leider veraltet sind und irgendeine Abhängigkeit auf eine nicht mehr vorhandene libgcc haben. Toll

Für heute mach ich mal Feierabend. In den nächsten Tagen wird das Image neu geflasht oder ein anderes verwendet. Vielleicht klappts ja dann. Folgender Thread hat mich doch etwas zuversichtlich gestimmt.

Java on Openmoko: Remote Tools

Hallo, jetzt habe ich schon einige Zeit nichts mehr hören lassen. Während ich nun den Klängen von Apocalyptica lausche gibts jetzt wieder eine feine Prise Java gemischt mit einem Hauch von Eclipse und das alles serviert auf einem frischen Neo Freerunner

Java on Openmoko: SWT läuft :)

Nach etwas Gebastel und Lesen von Mailing Listen habe ich nun SWT zum Laufen gebracht. Meine Meilensteine ändern sich nun wie folgend:

Java on Openmoko: Erste Erkenntnisse

Hier der aktuelle Status meiner Meilensteine für Java auf Openmoko:

Java on Openmoko

Nachdem ich jetzt endgültig keine Lust mehr habe, weiter nach einem Service-Component Tracker zu forschen, hat das Neo Freerunner nun wieder meine Kreativität beflügelt Ich überlege gerade, welche Art von Funktion ich wohl auf dem Handy implementieren könnte.

Service-Component Tracker: Was gibts Neues?

Nachdem jetzt längere Zeit nix mehr lief, hab ich heute Abend wieder etwas Zeit, mich um das Projekt zu kümmern:

Im letzten Lebenszeichen hatte ich noch die Absicht geäußert, den Code der DS-Implementierung genauer zu untersuchen. Das ist mir aber für den Anfang noch zu mühsam. Stattdessen habe ich zufällig gemerkt, dass das Bundle org.eclipse.equinox.ds den einen Service unter dem Interface org.osgi.service.cm.ConfigurationListener registriert. Ich werde mir daher zuerst das CM etwas genauer ansehen um evtl. noch Informationen zu den Service Komponenten darüber abzufragen.

CM steht für Configuration Managment Admin, dies ist ein besonderer Framework Service, der es erlaubt, Services mit ihren Parametern zu konfigurieren. Das Interface ConfigurationListener kann als Service im System angemeldet werden. Der Services wird dann automatisch bei allen Events des Admins benachrichtigt. Leider lassen sich darüber keine Informationen abfragen Mal sehen, ob DS noch weitere Schnittstellen nach außen hat.

Service-Component Tracker: Erste Hürden und Erkenntnisse

Nach dem Aufsetzen der Entwicklungsumgebung habe ich als Zweites den Source-Code von Equinox via CVS ausgecheckt, um bei meinen ersten Schritten etwas zu spicken.

Der erste Versuch war, ein eigenes Bundle zu schreiben, welches alle Funktionalitäten ohne Kenntnis der Interna des DS-Bundles implementiert. Das „services“ Kommando der Equinox hab ich deshalb auch als erstes angeschaut, da hier schon Name und ID der Service-Component angezeigt werden. Allerdings geschieht dies nicht, weil es Zugriff auf die Component hat, sondern weil Name und ID als Service-Properties dem Service hinzugefügt werden. Das Kommando zeigt einfach nur diese Properties an.

Aufbauend darauf habe ich schon einmal ein Bundle geschrieben, dass anhand dieser Properties die vorhandenen Service-Components mit Name und ID auflistet.

Auf der Suche im Internet bin ich dann noch auf die DS-Implementierung von Apache Felix gestoßen. Diese scheint schon etwas weiter entwickelt zu sein, hier gibt es das Kommando „scr“, welches Service-Components auflisten, anzeigen, starten und beenden kann. Dieser Link führt zu einer Beschreibung.

Für eine weitere Betrachtung der DS unter Equinox werde ich nicht umhin kommen, auch tiefer in den Sourcecode zu schauen. Auch wird es wohl darauf hinaus laufen, dass ich das Bundle org.eclipse.equinox.ds noch anpassen muss.

Projekt: Service-Component Tracker

Wie schon angedroht, werde ich jetzt mit einem kleinen Projekt zu Hause beginnen. Erstes Ziel soll die Erstellung eines Service-Component Trackers sein, einer Anwendung, welche die Service-Components einer OSGi-Umgebung suchen, anzeigen sowie verändern kann. Folgende Funktionen sollen bereitgestellt werden:

Projekt-Ideen

Da mir zwischen Arbeit, Fußball, Feuerwehr, Blogschreiben etc. immer noch genug Zeit bleibt, bin ich jetzt am Überlegen, ein kleines Open-Source-Projekt zu starten. Folgende Themen sollten darin vorkommen bzw. Technologien sollten genutzt werden:

• Java
• OSGi und Equinox
• Eclipse und RCP
• evtl. OpenGL (und wenns noch geht, Shader)
• evtl. EMF