Engywuck
Geowizard
Liebe Gemeinde,
auf Anregung von Pfeffer habe ich mich mal etwas mit den Zusammenhängen zwischen den verschiedenen Ewe-Librarys, die man im Repository findet, und den jeweiligen Einsatzzwecken beschäftigt. Meine Erkenntnisse sind vielleicht für den einen oder andern neu, deshalb will ich sie Euch nicht vorenthalten.
Basis - Was ist Ewe
Eve is a portable Virtual Machine that executes Java byte code (i.e. Java '.class' files) and has been specifically designed to run well on mobile devices as well as on the desktop.
Ewe ist also eine "kleine Java VM" mit abgespecktem und angepasstem Funktionsumfang. Aus diesem Grunde kann man für seine Ewe-Programme (wie CacheWolf) auch nicht die Java-Klassenbibliothek verwenden, sondern muss die Ewe-Klassenbibliothek verwenden.
Datei ewe.jar
Dies ist jene Ewe-Klassenbibliothek. Die Datei enthält nur die Class-Files, und diese auch in möglichst "sparsamer" Form, damit sie wenig Platz einnimmt, wenn man sie auf seinem mobilen Gerät in Einsatz nimmt. Deshalb enthält sich z.B. auch keine Debug-Informationen wie Zeilennummern.
Datei CompileEwe.zip
Dies ist ebenfalls die Ewe-Klassenbibliothek, allerdings diesmal mit Debug-Informationen.
Wann ewe.jar, wann CompileEwe.zip ?
Wird ein Programm kompiliert, um es in der Praxis zu betreiben, so werden die Klassen der Datei ewe.jar verwendet - die Debug-Informationen sind nämlich zum Betrieb des Programms nicht notwendig. Wird das Programm jedoch in einer Entwicklungsumgebung entwickelt, so werden stattdessen die Klassen der Datei CompileEwe.zip bekannt gemacht. So kann der Debugger der Entwicklungsumgebung auch im Einzelschrittmodus durch die Ewe-Klassendateien wandern.
Datei JavaEwe.zip
Inhaltlich ist diese Datei fast das gleiche wie CompileEwe.zip, mit zwei Unterschieden: Zum einen ist der Java-Sourcecode mit dabei, zum andern sind noch ein paar zusätzliche Klassen dabei. Wozu diese?
Wird ein Ewe-Programm nicht mit einer Ewe-VM gestartet, sondern mit einer normalen Java-VM (was zum Entwickeln sinnvoll ist, weil die EweVM keinen Debugger enthält), so braucht die Java-VM noch ein paar Klassen zusätzlich, damit sie richtig mit der Ewe-Library umgehen und das Ewe-Programm starten kann. Die EweVM selbst kennt diese Klassen nicht, deshalb dürfen sie im Programm auch nicht verwendet werden.
Fazit: Wenn ein Ewe-Programm mit einer JavaVM gestartet wird (z.B. in einer Entwicklungsumgebung), müssen die Klassen aus JavaEwe.zip verwendet werden.
Konfiguration in Eclipse
Soll in Eclipse entwickelt werden, so ergeben sich folgende Konsequenzen:
Einschub: Third-Party Klassen
Cachewolf braucht neben den eigentlichen Cachewolf-Klassen und der Ewe-Klassenbibliothek noch ein paar externe Klassen, die sich ebenfalls im Lib-Ordner befinden. Diese sind sowohl in die Classpath-Konfiguration wie auch in die Run-Configuration mit aufzunehmen.
So, bis hierhin die Grundlagen.
Ich habe mir das zu Herzen genommen und mal ein Testszenario aufgesetzt, in dem ich die Librarys so eingebunden habe, wie es eigentlich sein sollte. Das Ergebnis ist in folgendem Repository-Zweig zu finden: https://svn.berlios.de/svnroot/repos/cachewolf/experiments/engywuck/cp-test
Die Librarys im Verzeichnis lib habe ich etwas aufgeräumt:
Anpassen der Run-Configuration
Im Dialog, in dem man die Run-Configuration ändern kann, gibt es im Tab Common die Möglichkeit, den Speicherort der Run-Configuration anzugeben. Leider scheint es jedoch keine direkte Möglichkeit zu geben, eine so gespeicherte Run-Configuration einzulesen. Man muss sich deshalb mit folgendem Trick behelfen:
Klickt bei "Save as" auf "Shared File". Wenn ihr dahinter nichts angebt, wird im Rootverzeichnis Eures Projekts nach Klick auf "Apply" eine Datei mit Endung ".launch" erzeugt, die so heisst, wie Eure Run-Konfiguration. Ihr könnt nun diese Datei und die Datei CacheWolflaunch.default mit einem Texteditor öffnen und den Inhalt von CacheWolflaunch.default in Eure launch-Datei übertragen. Abspeichern - und danach sollte die Launch-Konfiguration so eingerichtet sein, wie es nötig ist.
Tja, soweit dieses etwas längliche Posting. Wäre toll, wenn ihr das mal ausprobieren könntet, ob es bei Euch auch klappt, und nicht nur bei mir. Und mit den jnf-Dateien könnte sich evtl. mal jemand austoben - solange man diese nicht anpasst, werden die exe-Dateien falsch generiert.
Wenn dann alles funktioniert und keiner Probleme meldet, sollte man diese Konfiguration so für die Entwicklungslinie übernehmen.
Ach ja: Wie ihr an dem SVN-Repository-Pfad oben sehen konntet: Ich habe unterhalb der Root-Ebene die Verzeichnisse experiments/engywuck eingerichtet. Wer also mal experimentieren will (und die Ergebnisse anderen zur Verfügung stellen), kann (z.B. mit TortoiseSVN) sehr leicht ebenfalls ein Unterverzeichnis einrichten und sich platz für Spielereien schaffen, ohne die Entwicklungslinie damit zu belästigen. Den Inhalt bekommt man dann leicht als Branch/Tag aus der Entwicklungslinie rüber...
So, das wärs erstmal.
Schöne Grüße,
Engywuck
auf Anregung von Pfeffer habe ich mich mal etwas mit den Zusammenhängen zwischen den verschiedenen Ewe-Librarys, die man im Repository findet, und den jeweiligen Einsatzzwecken beschäftigt. Meine Erkenntnisse sind vielleicht für den einen oder andern neu, deshalb will ich sie Euch nicht vorenthalten.
Basis - Was ist Ewe
Eve is a portable Virtual Machine that executes Java byte code (i.e. Java '.class' files) and has been specifically designed to run well on mobile devices as well as on the desktop.
Ewe ist also eine "kleine Java VM" mit abgespecktem und angepasstem Funktionsumfang. Aus diesem Grunde kann man für seine Ewe-Programme (wie CacheWolf) auch nicht die Java-Klassenbibliothek verwenden, sondern muss die Ewe-Klassenbibliothek verwenden.
Datei ewe.jar
Dies ist jene Ewe-Klassenbibliothek. Die Datei enthält nur die Class-Files, und diese auch in möglichst "sparsamer" Form, damit sie wenig Platz einnimmt, wenn man sie auf seinem mobilen Gerät in Einsatz nimmt. Deshalb enthält sich z.B. auch keine Debug-Informationen wie Zeilennummern.
Datei CompileEwe.zip
Dies ist ebenfalls die Ewe-Klassenbibliothek, allerdings diesmal mit Debug-Informationen.
Wann ewe.jar, wann CompileEwe.zip ?
Wird ein Programm kompiliert, um es in der Praxis zu betreiben, so werden die Klassen der Datei ewe.jar verwendet - die Debug-Informationen sind nämlich zum Betrieb des Programms nicht notwendig. Wird das Programm jedoch in einer Entwicklungsumgebung entwickelt, so werden stattdessen die Klassen der Datei CompileEwe.zip bekannt gemacht. So kann der Debugger der Entwicklungsumgebung auch im Einzelschrittmodus durch die Ewe-Klassendateien wandern.
Datei JavaEwe.zip
Inhaltlich ist diese Datei fast das gleiche wie CompileEwe.zip, mit zwei Unterschieden: Zum einen ist der Java-Sourcecode mit dabei, zum andern sind noch ein paar zusätzliche Klassen dabei. Wozu diese?
Wird ein Ewe-Programm nicht mit einer Ewe-VM gestartet, sondern mit einer normalen Java-VM (was zum Entwickeln sinnvoll ist, weil die EweVM keinen Debugger enthält), so braucht die Java-VM noch ein paar Klassen zusätzlich, damit sie richtig mit der Ewe-Library umgehen und das Ewe-Programm starten kann. Die EweVM selbst kennt diese Klassen nicht, deshalb dürfen sie im Programm auch nicht verwendet werden.
Fazit: Wenn ein Ewe-Programm mit einer JavaVM gestartet wird (z.B. in einer Entwicklungsumgebung), müssen die Klassen aus JavaEwe.zip verwendet werden.
Konfiguration in Eclipse
Soll in Eclipse entwickelt werden, so ergeben sich folgende Konsequenzen:
- In den Classpath muss die Datei CompileEwe.zip aufgenommen werden. Grund: Für das Programm, dass ich entwickle, sollen Debug-Informationen zur Verfügung stehen (daher CompileEwe.zip und nicht ewe.jar), und ich soll nur die Klassen zur Verfügung haben, die die Ewe-VM auch kennt (daher CompileEwe.zip und nicht JavaEwe.zip). ewe.jar oder JavaEwe.zip haben hier nichts zu suchen!
- In den Classpath der Run-Configuration muss JavaEwe.zip aufgenommen werden, während CompileEwe.zip nicht vorhanden sein darf. Grund: Die Run-Configuration wird nur verwendet, wenn Eclipse (und damit die Java-VM) das Programm startet. Und die Java-VM braucht (s.o.) JavaEwe.zip als Klassenbasis. Auch in der Run-Configuration sollte ewe.jar nicht vorkommen.
- Da JavaEwe.zip inhaltlich (fast) identisch ist mit CompileEwe.zip, kann die Datei als Sourcecode-Quelle für CompileEwe.zip (in der Classpath-Konfiguration) genutzt werden.
Einschub: Third-Party Klassen
Cachewolf braucht neben den eigentlichen Cachewolf-Klassen und der Ewe-Klassenbibliothek noch ein paar externe Klassen, die sich ebenfalls im Lib-Ordner befinden. Diese sind sowohl in die Classpath-Konfiguration wie auch in die Run-Configuration mit aufzunehmen.
So, bis hierhin die Grundlagen.
Ich habe mir das zu Herzen genommen und mal ein Testszenario aufgesetzt, in dem ich die Librarys so eingebunden habe, wie es eigentlich sein sollte. Das Ergebnis ist in folgendem Repository-Zweig zu finden: https://svn.berlios.de/svnroot/repos/cachewolf/experiments/engywuck/cp-test
Die Librarys im Verzeichnis lib habe ich etwas aufgeräumt:
- Die Dateien ewe.jar und CompileEwe.zip sind in ein Unterverzeichnis compile gewandert.
- Die Datei JavaEwe.zip ist in ein Unterverzeichnis Ewe4JavaVM gewandert.
- Die zusätzlichen Third-Party-Klassen (bislang ab Unterverzeichnissen com, ewesoft und HTML sind in ein Unterverzeichnis additional gewandert.
- Die Datei .classpath ist so angepasst, dass sie nun "passt".
- Die passende Run-Configuration wurde in einer Datei abgespeichert. Deren Inhalt steht in Datei CacheWolflaunch.default im Rootverzeichnis zur Verfügung. Wie man sie verwendet: Siehe unten.
- Die sonstigen Dateien (*.bat, *.sh) habe ich so angepasst, dass sie die neue Verzeichnisstruktur beherzigen.
- Die Datei runjewel.bat funktioniert jetzt wieder.
- Hier hab ich noch Schwierigkeiten: Die jnf-Dateien habe ich noch nicht auf die neue Verzeichnisstruktur trimmen können. Ich hab Jewel probiert, das Verzeichnis lib/additional bekannt zu machen, aber das hat noch nicht funktioniert. Er hat keine Dateien darin gesehen... Vielleich kommt jemand von Euch weiter?
Anpassen der Run-Configuration
Im Dialog, in dem man die Run-Configuration ändern kann, gibt es im Tab Common die Möglichkeit, den Speicherort der Run-Configuration anzugeben. Leider scheint es jedoch keine direkte Möglichkeit zu geben, eine so gespeicherte Run-Configuration einzulesen. Man muss sich deshalb mit folgendem Trick behelfen:
Klickt bei "Save as" auf "Shared File". Wenn ihr dahinter nichts angebt, wird im Rootverzeichnis Eures Projekts nach Klick auf "Apply" eine Datei mit Endung ".launch" erzeugt, die so heisst, wie Eure Run-Konfiguration. Ihr könnt nun diese Datei und die Datei CacheWolflaunch.default mit einem Texteditor öffnen und den Inhalt von CacheWolflaunch.default in Eure launch-Datei übertragen. Abspeichern - und danach sollte die Launch-Konfiguration so eingerichtet sein, wie es nötig ist.
Tja, soweit dieses etwas längliche Posting. Wäre toll, wenn ihr das mal ausprobieren könntet, ob es bei Euch auch klappt, und nicht nur bei mir. Und mit den jnf-Dateien könnte sich evtl. mal jemand austoben - solange man diese nicht anpasst, werden die exe-Dateien falsch generiert.
Wenn dann alles funktioniert und keiner Probleme meldet, sollte man diese Konfiguration so für die Entwicklungslinie übernehmen.
Ach ja: Wie ihr an dem SVN-Repository-Pfad oben sehen konntet: Ich habe unterhalb der Root-Ebene die Verzeichnisse experiments/engywuck eingerichtet. Wer also mal experimentieren will (und die Ergebnisse anderen zur Verfügung stellen), kann (z.B. mit TortoiseSVN) sehr leicht ebenfalls ein Unterverzeichnis einrichten und sich platz für Spielereien schaffen, ohne die Entwicklungslinie damit zu belästigen. Den Inhalt bekommt man dann leicht als Branch/Tag aus der Entwicklungslinie rüber...
So, das wärs erstmal.
Schöne Grüße,
Engywuck
