Schlagwort: Gradle

Was ein Gefuddel für Android

Nachdem mir die Raspberry PIs als auch vergleichbare Platinen im Moment einfach zu teuer sind, habe ich mich daran gemacht, ein uraltes Notebook, dass ich vor einigen Monaten mit Deepin Linux neu eingerichtet habe, für die Cordova-Entwicklung einzurichten. Das ist zwar fertig, liegt aber sowieso da rum und einen Test war es mir wert.

Im Grunde geht das Einrichten von Cordova ja auch recht einfach, wenn es nicht die elenden Fallen geben würde.
Einmal ist da im Fall von Android das Problem mit der Java-Version. So richtig geht es – falls man für Android die App erstellen will – nur mit Java 8 bzw. dem JDK 8. Das Problem habe ich schon vor gefühlten Ewigkeiten bemerkt und mir immer damit geholfen, dass ich eben Java 8 installiert habe. Neben den aktuellen Versionen. Leider ist es dann aber blöde, weil man für Gradle-Skripte (zumindest die vorgefertigten von Cordova) die Default-Version von Java auch auf eben dieses Java 8 umstellen muss. Das geht in Linux (Debian, Ubuntu, Mint und Derivate) so:

sudo update-alternatives --config java

In der Folge kann man zwischen den installierten Java-Versionen auswählen und eine davon zur Default-Version machen. Aber dann muss man dann auch noch JAVA_HOME korrekt setzen. Etwa so:

env JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

oder

export JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

Ging unter Deepin als normaler User, aber komischer Weise hat das als root nicht funktioniert bzw. die Einstellungen wurden nicht übernommen. Letztendlich habe ich viel rumgebastelt, wieder viel gelernt, bin aber wie so oft im Grunde gescheitert.
Wobei das Problem mit Java 8 ist vermutlich ein ganz anderes, als man vermutet. Denn vor einigen Monaten hatte ich eine Schulung rund um Java EE gehalten und da hatten wir bei JSF ein ähnliches Problem. Die Meldung sah so aus als wäre die Version von Java nicht passend bzw. zu alt, obwohl sie neuer als die geforderte/angezeigte Version war. Ganz wie hier bei Cordova. Aber dann ist mir aufgefallen, dass die Versionsnummern in dem Framework nur einstellig (!) evaluiert wurden. Also Java 11 oder Java 17 werden als Java 1 interpretiert. So was vermute ich mittlerweile auch bei Cordova bzw. den Gradle-Skripten. Man müsste es mal mit Java 9 testen, aber dazu habe ich im Moment keine Zeit.
Letztendlich ist aber sowieso das Hauptproblem dieses elende Android-Gefuddel. Das Android-SDK und die Android-Tools etc. habe ich nach und nach alle installiert, aber ständig kam die Meldung, dass das Zeug nicht da wäre. Genaugenommen hat das Gradle-Skript diese Meldung gebracht. Letztendlich habe ich sogar das Android Studio auf dem uralten Notebook mit Deepin installiert, dort diverse Fernzugriffservice eingerichtet und gestartet, alle möglichen SDK-Versionen nachinstalliert und sogar ein Cordova-Template im Android Studio als Plugin eingerichtet.
Resultat – das Gradle-Skript weigert sich, die Android-Ressourcen zu finden. Und selbst das Android Studio nimmt dieses Gradle-Skript und kennt sich quasi dann selbst nicht mehr.

Irgendwann hatte ich die Faxen dicke, denn so schön Deepin Linux von der Oberfläche auch ist – es hat so ein paar Macken, die ich von der administrativen Seite nicht wirklich gut finde. Und der VNC- als auch RDP-Zugriff haben darauf ums Verrecken nicht funktioniert. Nur ssh – auch mit X-Umleitung von einem anderen Linux-Rechner.
Apropos anderer Linux-Rechner – das ist mein Terra-Notebook, auf dem ich Windows 10 und Mint Linux im Dualboot betreibe. Unter Windows habe ich das Cordova (auch für Android) mit Visual Studio 2017 im Griff (und im Prinzip auch mit dem Android Studio – das macht aber keinen Spass). Die Linux-Version kann ich aber seit Monaten nicht mehr aktualisieren oder da ein Programm installieren. Die Sache hier war für mich der Anlass, dass Problem mal anzugehen. Denn egal was ich probiert habe die letzte Zeit – mit der Fehlermeldung, dass die Quellen nicht zu lesen wären, haben sämtliche Aktualisierungsversuche als auch Installationsversuche abgebrochen.
Ich bin nun auf den Lösungsansatz gestoßen, dass man die Datei mit einem geeigneten Repo füllen sollte. Etwa das:

sudo nano /etc/apt/sources.list
deb http://de.archive.ubuntu.com/ubuntu bionic main restricted

Habe ich gemacht – keine Wirkung!
Dann habe ich endlich die Meldung genauer angesehen – Linux hat nicht die Datei /etc/apt/sources.list beim Installieren/Aktualisieren ausgelesen, sondern die Datei /etc/apt/sources.list.d/vivaldi.list.
Aus irgendeinem Grund wurde der Pfad umgebogen. Wo genau, habe ich noch nicht raus, aber einfach das Repo da reingeschrieben. Und gut ist es – aktualisieren und installieren geht wieder.
Jetzt kann ich auch mal den Linux-Rechner nutzen und versuchen, da Cordova-Apps für Android zu kompilieren. Wenn das auch da nicht geht, habe ich ja immer noch Visual Studio 2017 und meinen Docker-Container.

Und so ganz unwahrscheinlich ist es nicht, dass ich darauf beschränkt bleibe. Denn bei dem Mint-Linux ist node.js und damit auch npm in einer alten Version dabei. Was nicht schlimm wäre, wenn nicht jede Art der Installation, die ich versucht habe, immer diese uralte Version 8 installiert hätte. Mit apt bzw. apt-get entfernt, neu installiert, andere Quellen genommen, verschiedene Package-Manager ausprobiert -> immer die Version 8, obwohl es schon die Version 18 gibt. Ein Problem führt bei den ganzen Aktionen – wie eigentlich immer – zum nächsten.

Ich bin jetzt auf das Level zurückgegangen, dass ich die Quellcodes von Git geholt und dann bei mir neu kompiliert und installiert habe.

Also klassisch

git clone https://github.com/joyent/node.git

Und dann:

./configure
make
make install

Dazu gibt es im Netz eine ziemlich gute Anleitung.

Der kleine Hinweis dort, dass das Kompilieren ein „bisschen länger“ dauert, war aber untertrieben. Ich bin mit der Erwartung von vielleicht 30 Minuten maximal in den make-Befehl rein und nach gut 5 Stunden war noch kein Ende zu sehen. Das Zeug ist dann über Nacht durchgelaufen und heute morgen war es erledigt. Das dauert also brutal lang, wobei mein Terra-Notebook auch schon in die Jahre gekommen ist.

Anyway – die Sache ging durch und nun habe ich node.js bzw. npm in der Version 18. Cordova ist damit auch eben fix installiert und wie es mit Android aussieht, schaue ich mir später an. Das ist ja die einzige kritische Stelle.

 

Neu erschienen – mein JavaFX Grundkurs bei LiL

Über den Sommer habe ich mehrere Training bzw. Aktualisierungen für LinkedIn Learning eingespielt, deren endgültige Fertigstellung bzw. Produktion sich dann doch ziemlich hingezogen haben. Nicht zuletzt Corona hat Arbeitsabläufe und Kapazitäten sowie Prioritäten im Griff,. Aber die Woche ging es wie beim Bretzelbacken und neben der Aktualisierung meines Training zu den Neuerungen der verschiedenen Versionen von Java und meinem aktuellen Entwickler-Tipp zu Python ist diese Woche auch der JavaFX Kurs erschienen. Dabei geht es neben JavaFX auch um FXML und den Sceen Builder sowie NetBeans, Maven, Ant, Gradle, JDK etc..

Ich habe schon früher Kurse zu JavaFX eingespielt (sogar schon zu Zeiten von Video2Brain (V2B), aber auch dann Aktualisierungen für LiL), aber die sind mittlerweile komplett veraltet. Der neue JavaFX Kurs ist deshalb vollkommen neu konzipiert und vollständig neu eingespielt. Außer ein paar Ideen für Beispiele ist nichts mehr identisch zu den alten Kursen.

Was übrigens auch JavaFX als Technologie betrifft. Diese hat sich zum Teil komplett inkompatibel zu älteren Versionen weiterentwickelt. Offiziell heisst sie jetzt sogar nicht mehr JavaFX, sondern OpenJFX und wird nicht mehr von Orcale verantwortet, sondern einer OpenSource-Organisation. Wobei sich der Bezeichner „OpenJFX“ wohl nicht so richtig etablieren will und man deshalb an den meisten Stellen doch wieder den ursprünglichen Bezeichner „JavaFX“ beibehält.

JSF/MyFaces, Microservices, Maven & Co

Ich habe die ersten drei Tage der Woche eine Einzelschulung zu erweiterten Java-Themen gehalten. Es ist kaum zu glauben, aber das war die erste Live-Schulung seit 1,5 Jahren. Obwohl ich in der Zeit sogar sehr viele Schulungen gehalten habe, waren sie allesamt online.
Bei der Schulung ging es grob gesagt um Java. Aber keine Einsteiger-Themen, sondern um eine Betrachtung diverser Themen im Java-Umfeld samt Web für einen erfahrenen Programmierer, der sich mit den Techniken bereits auskennt. So Sachen wie

  • JUnit, Git und Github,
  • Maven und andere Build-Tools wie Gradle und Ant,
  • Docker,
  • Übersicht neue Java-Techniken (vor allen Dingen Lambda-Ausdrücke, Closures und das Modulsystem)
  • JavaFX/OpenJFX/FXML
  • Ausblick Mobile, Android Studio, Cordova
  • Tomcat bzw. Java-Container als Server (Wildfly)
  • JSP/Servlets/JSF
  • Refactoring
  • Microservices (Spring)

Bei der Anfrage hat mich allerdings das Thema JSF (Java Server Faces) doch schwer verwundert. Ich hatte in der Vergangenheit JSF durchaus mehrfach geschult, aber seit Jahren eigentlich nichts mehr damit zu tun. Und ich bin davon ausgegangen, dass das Thema JSF eigentlich ziemlich out ist. So hatte ich das auch schon vor einigen Jahren beurteilt und mich deshalb aus dem Themenkomplex weitgehend zurückgezogen. Die vereinzelten Anfragen zu JSF-Kursen habe ich auch immer abgelehnt. Überhaupt sah und sehe ich bei den Java-Frameworks für das Web eigentlich nicht (mehr) das große Potential. Weder bei JSF (oder gar Servlets/JSP), noch Spring oder Struts.

Aber mein Teilnehmer wechselt demnächst beruflich als IT-Leiter in eine Behörde, die wohl mit JSF 2.3 arbeitet. Alttechnologien halten sich oft ewig. Ich habe ja auch einen Standardkunden, der noch mit Cobol arbeitet.

Da diese Schulung als eine Art Workshop mit Wissensaustausch gewünscht war und JSF etc. nur einen Teil der Agenda ausgemacht hat, habe ich die Sache angenommen. JSF und Web haben wir dann auch geschlossen am dritten Tag abgearbeitet.

Rückblickend war es auch verdammt spannend, sich wieder in die Welt von JSF einzuarbeiten. Wobei dabei uns beim Voranarbeiten ganz interessante Phänomene untergekommen sind, von denen mir immer noch nicht ganz klar ist, ob wir auf den Grund der Tatsachen getaucht sind oder uns verirrt haben.

Gerade bei Java im Web-Umfeld ist m.E. erst einmal die Konfiguration die größte Einstiegshürde. Vor allen Dingen, wenn man da nicht täglich am Schaffen ist. Das fängt schon mit der Konfiguration der Server an. Ganz banal bei der lästigen Tomcat-Einstellung in der Datei tomcat-users.xml, wo mit

<role rolename="manager-gui"/>

<user username="admin" password="admin" roles="standard,manager-script,manager-gui" />

erst einmal freigeschaltet werden muss, dass der Server über das Webinterface administriert werden kann und war-Dateien überhaupt deployed werden dürfen. Mit Wildfly ist es auch nicht einfacher bzw. bequemer.

Da Maven in der Schulung ein großes Thema war, haben wir viel mit Architypes gearbeitet. Auch bei JSF, was wir in der Version 2.3 als Basis genommen haben. Neben den Schablonen in Netbeans und Eclipse, die mit Maven, Ant oder Gradle arbeiten.

Neben dem elenden Konfigurieren über die web.xml und die faces-Konfigurationsdateien gab es ganz ungewöhnliche Probleme mit dem Kompilieren bzw. Deployen der Projekte. Vor allen Dingen Projekte, die ich schon zum Laufen gebracht hatte, als auch die generierten Projekte aus den POM-Dateien wurden vielfach nicht übersetzt oder konnten nicht auf den Tomcat depoyed werden. Teils gingen auch die SSI-Dateien mit den Tag-Libs, aber alleine die Existenz einer Java-Datei im Projekt hat die Übersetzung blockiert. Nicht einmal als Bean oder Controller gebaut, sondern eine leere Klasse im source-Verzeichnis hat genügt, um einen Fehler zu erzwingen.
Andere Projektkonfigurationen haben die Java-Controler und -Beans übersetzt, aber die xhtml-Dateien wurden auf dem Server nicht geparst und damit die Tag-Libs nicht verarbeitet.
In Netbeans gab es bei dem Problemen mit dem Java-Code die unverständige Fehlermeldung, dass source in der Version 6 nicht mehr unterstützt wird und wir die Version 7ff nehmen sollten. Nach diversen Problemen habe ich auf mein Matebook als Ursache getippt, aber auf dem Teilnehmerrechner waren die Fehler exakt reproduzierbar.
Irgendwann hatte ich die Faxen dicke und habe auf einem alten Linux-Rechner die Geschichte von Grund auf neu aufgesetzt. Also zuerst Maven, was noch nicht da installiert war, und dann einen Architype für JSF mit der Konsolenanwendung mvn aus dem Internet gezogen. Damit hat die Sache von A bis Z funktioniert und mir ist aufgefallen, dass ich auf dem Linux-Rechner das OpenJDK 8 installiert habe. Auf unseren beiden anderen Rechnern allerdings das JDK 16 und bei meinem Teilnehmer das JDK 15. Und danach haben wir endlich in einer Konfigurationsdatei zu den JSF 2.3 die XML-Tags gefunden, dass die Entwickler- als auch Zieldatei auf Java 8 festgelegt ist.
Unter dem Gesichtspunkt macht auch die Fehlermeldung von Netbeans Sinn – es müsste bei mir eigentlich heißen source in der Version 16, aber das Feld für die Versionsnummer wurde wohl nur einstellig konzipiert. Aus der 16 wurde die 6 und damit eine vollkommen unsinnige Fehlermeldung. Aber zum Zeitpunkt, wo die JSF 2.3 konzipiert wurden, hatte man vermutlich nicht an Inkompatibilitäten in so hohen Folgeversionen, sondern nur älteren Versionen, gedacht. Wir sind nicht so ganz sicher, ob die JSF bis zur Version 2.3 mit den neuen JDK nicht mehr klar kommen, aber ich denke schon. In der Doku steht explizit auch die Version 8. Das deckt sich mit der Tatsache, dass Cordova auch nur bis zur JDK-Version 8 funktioniert. Das habe ich ja in meiner Vorlesung an der TH Bingen die Tage behandeln müssen.
Die JSF werden wohl als Apache MyFaces weiterentwickelt und stehen mittlerweile in der Version 4.0 zur Verfügung, aber die haben wir uns dann nicht mehr genauer angesehen.

Rund um das Thema habe ich auch noch ein paar nützliche Anleitungen gefunden:

JSF Tutorial
https://www.javawebtutor.com/articles/jsf/
https://www.tutorialspoint.com/jsf/jsf_overview.htm

JSF in Tomcat zum Laufen bringen
https://www.byteslounge.com/tutorials/how-to-configure-jsf-in-tomcat-example

Webanwendungen als Docker-Images herstellen
https://jaxenter.de/apache-tomcat-meets-docker-webanwendungen-als-docker-images-herstellen-23213

Grundsätzlich hat sich mein Eindruck gefestigt, dass im Web Java nicht (mehr) der Bringer ist. Irgendwie reihen sich JSF/MyFaces in andere Projekte wie JavaFX/OpenJFX oder auch Cordova ein, bei denen die Originalhersteller die Entwicklung abgetreten haben und wo es aus meiner Sicht nicht sicher ist, dass diese Projekte auf Dauer sich halten und/oder zuverlässig weiterentwickelt werden.

Wobei die Erstellung eines Spring-Microservice für Tomcat wirklich genial einfach war und die mit einer Anleitung erstellte Version des Microservice absolut flexibel und einfach an beliebige Bedürfnisse anzupassen ist.

Vorteile und Graus der Virtualisierung – Docker & Co

Cordova

Da ich für das kommende Sommersemester an der Technischen Hochschule Bingen wieder einen Lehrauftrag zum Thema Cordova und plattformneutrale App-Entwicklung angenommen und gerade Zeit für die Vorbereitung habe, habe ich die letzten Tage in den aktuellen Stand von Cordova reingeschaut und meine alten Projekte und Matrialien zusammengetragen. Ich hatte dieses Thema eine ganze Weile schleifen lassen, da Python, Big Data, Web-Programmierung, Cobol, C# & „Was auch sonst immer“ die Arbeit in eine andere Richtung gelenkt hatten.

Die meisten Dinge, die ich die vergangenen Jahre zusammengestellt und programmiert habe, sind jedoch noch weitgehend auf Stand. Allerdings haben sich auch durchaus Sachen geändert. Daher bedarf die neue Vorlesung einiger Vorbereitung und eine Anpassung.

Zudem habe ich auch ganz einfach Lust, meine ganzen Apps zu aktualisieren. Parallel will ich aus einigen Apps  Python-Programme machen. Ohne konkrete Ziele, aber vielleicht kommen mir dabei ein paar neue Ideen und ich lerne natürlich was dazu – auch wenn das im Grunde aktuell ein reines Programmieren aufgrund von Zeit und Lust darstellt.

Anyway – bei Cordova gibt es ein paar Sachen, die mich schon stutzig gemacht und zu einigen Arbeiten im Hintergrund sowie grundsätzlichen Überlegungen genötigt haben. Das reine Installieren der neuen Version von Cordova mit npm geht wie gehabt und das Erstellen von Cordova-Projekten in dem Cordova-CLI auch. Ebenso das Hinzufügen der verschiedenen Plattformen und das Ausführen in dem Browser-Emulator ist unverändert. Die eigentlichen Quellcodes auf Basis von JavaScript & Co sowieso.

Aber wenn man etwa beim konkreten Kompilieren Android als Plattform für die Cordova-Apps haben will, wird das JDK 8 vorausgesetzt. Im Moment ist aber schon das JDK 15 aktuell und damit funktioniert es nicht. Zumindest bekomme ich es im Moment nicht hin, mit der derzeit aktuellen Java-Version Android-Apps zu erstellen. Ehrlich gesagt ist mir nicht einmal klar, ob das an Android (da soll ja Java auch sukzessive abgelöst werden) oder Cordova liegt. Wie angedeutet, habe ich die App-Entwicklung eine Weile aus den Augen verloren.

Und dann hatte ich das Android Studio bzw. das Android SDK als auch Xcode komplett von meinen Rechnern gelöscht, da ich eben das Entwickeln für Android und iOS die letzte Zeit nicht gebraucht hatte. Zumal ich mich sowieso auch dabei auf das Visual Studio committed hatte. Dabei kann man ja wunderbar auch Android- bzw. iOS-Apps erstellen.

Aber um die verschiedenen Möglichkeiten im Vorfeld der Vorlesung mal wieder auszutesten, werde ich auf meinem Mac vermutlich Xcode neu installieren (wenn ich die Sache mit meiner Apple-ID geklärt habe – die habe ich auslaufen lassen) und das Android Studio habe ich mittlerweile wieder neu installiert.

Aber irgendwie hat es bei meinem ersten naiven Versuch nicht funktioniert, damit Cordova-Projekte zu öffnen – oder besser –  zum Laufen zu bringen. Irgendwie mag ich das Android Studio aber auch nicht wirklich. Ich sollte der Sache zwar auf den Grund gehen, aber ich werde ja sowieso Visual Studio nehmen.

Wobei es da auch ein seltsames Problem gibt. In Visual Studio 2019 ist die Erweiterung für Cordova nicht mehr dabei und damit kann man weder Cordova-Projekte anlegen noch vorhandene Cordova-Projekte öffnen. Also musste ich die schon gelöschte Version 2017 von Visual Studio mit der Cordova-Erweiterung wieder auf meine Rechner aufspielen. Damit geht aber alles wunderbar und ich habe mittlerweile diverse Cordova-Apps erstellt, aus Visual Studio in verschiedenen Emulatoren sowie per USB-Debugging sogar direkt auf mehreren Geräten ausgeführt. Auch die Installation auf ein paar Testgeräten funktioniert problemlos. Seltsam sind die Begleiterscheinungen jedoch schon und ich bin nicht sicher, ob Cordova noch lange auf dem Markt bleibt. Was Cordova aber nicht als gute Basis für die kommende Vorlesung diskreditiert, um grundsätzlich die Erstellung von plattformneutralen Apps auf Basis von Webtechnologien zu lernen. Denn im Umfeld von Xamarin sind die gleichen Bedingungen/Probleme vorzufinden. Die Frage ist also wohl eher, ob Apps auf Basis von Webtechnologien sich auf Dauer etablieren oder nicht?

Wie dem auch sei – ich habe eigentlich keine Lust, das alte JDK 8 auf meine Rechner zu installieren und auch nicht die ganzen Emulatoren und SDKs von Android Studio auf Teufel komm raus zu konfigurieren. Entweder es geht „out-of-the-box“ wie bei Visual Studio 2017 oder die Sache kann mir im Grunde gestohlen bleiben. Es geht mir um die eigentlich Programmierung innerhalb des Cordova-Wrappers mit JavaScript und HTML/CSS und nicht um das Geraffel rundherum. Das hat mich schon immer an der App-Programmierung genervt.

Und da kam ich auf die Idee, eine andere Sache mal wieder aufzugreifen, die ich vor einigen Monaten angefangen, dann aber wegen anderer Dinge – wie so oft – beiseite gelegt habe: Docker.

Warum nicht einfach ein gut konfiguriertes Docker-Image für Cordova laden und dann ohne das ganze Installieren und Konfigurieren die Apps bauen? Das war meine Idee. Sollte doch einfach sein.

Und wie immer, wenn etwas auf den ersten Blick so einfach und logisch aussieht, steckt der Teufel im Detail. Genau genommen sind es in dem Fall sogar gleich mehrere Teufel gewesen.

Denn obwohl ich mich schon mit Docker beschäftigt und auch schon Images bzw. Container zum Laufen gebracht hatte, habe ich das Zeug zwischenzeitlich wieder von meinen Rechner gelöscht gehabt. Also musste ich Docker erst einmal „schnell“ installieren. Was (natürlich) wieder gar nicht schnell war und letztendlich sogar auf meinen Windows-Rechnern gescheitert ist. Weder unter Windows 10 Pro noch unter Windows 10 Home ist Docker bei mir richtig gelaufen. Natürlich kam ich bei den Problemen mit Windows 10 Pro sofort auf Hyper-V und diesen ganzen Virtualisierungs-Kram im Hintergrund von Windows, denn damit habe ich schon seit Jahren Ärger im Zusammenspiel mit VirtualBox und dem VMWare Player. Und auch wenn der VMWare Player ab der Version 16 wohl mit dem Hyper-V-Geraffel kann und auch Docker in Windows 10 Pro irgendwas mit Hyper-V macht und ich die Anleitungen für die ganzen Einstellungen umgesetzt habe, hat das Zeug irgendwelche Probleme mit den Rechten. Dazu kommt – bei Windows 10 Home gibt es ja kein Hyper-V und da muss man dann andere Sachen konfigurieren bzw. installieren. Alles doch ein elendes Gefuddel, was ich ja ausdrücklich vermeiden wollte und ich habe nach diversen Versuchen die Lust verloren.

Also auf meinen Linux-Rechner gewechselt, auf dem Docker erwartungsgemäß problemlos läuft. Zwischenzeitlich war ich auch in Eppstein und habe Docker mal auf meinem iMac getestet – auch keine Probleme. Also Docker sollte doch ein lohnenswerter Ansatz sein.

Aber dann bin ich auf das nächste blöde Problem gestoßen, erst einmal ein geeignetes Cordova-Image für Docker zu finden. Auf Git gibt es da was, aber der Git-Zugriff scheitert durch Rechteprobleme. Das Image scheint entweder gesperrt oder verschoben worden zu sein. Dann habe ich noch eine Anleitung gefunden, wie ich mir selbst ein Cordova-Image erstellen kann, aber das ist ja das Gegenteil von dem, was ich eigentlich wollte – keine Arbeit mit der blöden Konfiguration. Letztendlich habe ich nur ein Docker-Image gefunden, dass (angeblich) mit einem einfache Pull vom Docker Hub zu installieren wäre. Also so (vermutlich als root notwendig):

sudo docker pull beevelop/cordova:latest

Das Starten des Image soll dann einfach so funktionieren:

sudo docker run -it beevelop/cordova bash

Unter Windows habe ich wie gesagt Docker nicht stabil zum Laufen gebracht und das Image wurde angeblich nicht gefunden. Beim iMac muss ich es noch probieren, aber auf meinem Linux-Rechner ging der Pull einwandfrei. Bis 98% durch waren. Dann kam reproduzierbar immer wieder der Abbruch.

Mittlerweile war es Krieg – die Technik gegen mich. Oder umgekehrt. Und wenn etwas einfach nicht laufen will, werde ich zum Berserker. Auch wenn im Grunde alles Notwendige zur Vorlesung über Cordova mit Visual Studio bereit gestanden hat – ich lasse mich doch nicht von so einem Mist in die Knie zwingen.

Mein Mint Linux-Rechner ist noch in der Version 19 und das System wollte ich auch nicht verpfuschen. Von daher kam mir die Idee, meine Linux-VM (Mint Linux 20) unter Windows 10 zu verwenden. Nur konnte die plötzlich auf meiner Workstation mit VirtualBox nicht mehr gestartet werden und auch die Installation einer neuen Linux-VM ist gescheitert. Möglicherweise aufgrund der Hyper-V-Einstellungen und dem Kram, aber ich hatte einfach keinen Bock mehr auf das Gefummel. Also eine neue Version von VMWare-Player aufgespielt, dort eine Version von Mint-Linux 20 installiert und da ging dann der Pull des Docker-Images. Ohne Probleme. Wenn man „Von hinten durch das Auge“ wortwörtlich haben will, ist das diese Konstruktion – eine Virtualisierung in einer Virtualisierung.

Wer aber jetzt glaubt, die Sache wäre vorbei, täuscht sich. Denn in dem Cordova-Image war kein passendes JDK 8 dabei. Die Erstellung eines Cordova-Projekts ging damit problemlos, aber das geht ja auch in meiner normalen Cordova-CLI und damit bringt mich ein Docker-Image keinen Millimeter weiter.  Als ich eine Android-App kompilieren wollte, war war auch im Docker-Container Schicht im Schacht.

Aber es war mittlerweile schon lange persönlich und jetzt wollte ich es durchziehen. Also in dem Docker-Container das JDK 8 nachinstalliert. Das geht so:

apt-get update && apt-get install -y openjdk-8-jdk && apt-get install -y ant && apt-get install -y gradle && apt-get clean

Unter Umständen tut ein Update der Zertifikate noch gut (bei mir nicht notwendig gewesen):

apt-get update && apt-get install ca-certificates-java && apt-get clean && update-ca-certificates -f

Und letztendlich müssen u.U. die Umgebungsvariablen gesetzt werden (bei mir auch nicht mehr notwendig gewesen):

ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

oder

set JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

und dann:

export JAVA_HOME

Danach konnte ich endlich eine Android-App im Docker-Container kompilieren. Nur sind Docker-Systeme ja flüchtig und wenn der Docker-Container beendet wird, sind alle Änderungen samt der gespeicherten Daten weg. Also waren Snapshots des aktuellen Stands notwendig. Das geht aus einem zweiten Terminal heraus etwa so:

sudo docker commit -p 532a5b3584e8 container1

Dabei braucht man die ID oder den Namen des Docker-Containers.Bekommt man so:

sudo docker ps

Dann bekommt man was der Art angezeigt:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
532a5b3584e8 container1 „bash“ 19 minutes ago Up 19 minutes eloquent_liskov

Und dann muss die kompilierte App ja auch noch raus aus dem Docker-Container oder man muss was reinkopieren. Also stellte sich die Frage, wie man aus einem zweiten Terminal aus dem Clientsystem auf den Host rauskopiert oder umgekehrt? Das geht formal so (wieder mit sudo):

docker cp <SRC> <DEST>

Also konkret was der Art (in den Container):

sudo docker cp /home/ralph/Schreibtisch/www eloquent_liskov:/tmp/HalloWelt
sudo docker cp /home/ralph/Schreibtisch/rjsedv.jks eloquent_liskov:/tmp/HalloWelt
sudo docker cp /home/ralph/Schreibtisch/build.json 532a5b3584e8:/tmp/HalloWelt

Aus dem Container auf den Host geht für die generierte Android-App etwa so:

sudo docker cp eloquent_liskov:/tmp/HalloWelt/platforms/android/app/build/outputs/apk/debug/app-debug.apk /home/ralph/Schreibtisch

Die späteren Neustarts der Snapshots zeigten, dass noch (weitgehend) alle Daten waren und jetzt schien alles ok.

Pustekuchen. Denn auf meinem Notebook mit Windows 10 Home konnte der VMWare-Player die virtuelle Maschine nicht starten, die ich auf der Workstation erstellt hatte. Und ist auch beim Neuinstallieren eines Linux-Systems gescheitert. Irgendwas mit der Anzeige ging schief. Warum auch immer.

Also habe ich auf dem Notebook VirtualBox genommen, denn das ist dann dort im Gegensatz zum VMWare Player auch mit Linux als Clientsystem sauber gelaufen. In der damit erzeugten VM für Mint-Linux 20 das ganze Zeug mit Docker nochmal gemacht und das hat dann auch funktioniert.

Letztendlich hat das „Mal schnell“ zu gut einem vollen Tag Arbeit geführt, aber ungelöste Probleme lassen mir keine Ruhe und ich habe dabei vor allen Dingen wieder eine Menge gelernt. Vielleicht kann ich das neue Wissen ja nochmal brauchen.

 

Update: Irgendwann habe ich dann festgestellt, dass das Docker-Cordova-Image die Cordova-Version 9 verwendet hat und mittlerweile die Version 10 aktuell ist. Was im Grunde nicht schlimm ist, aber so kann man das dann im Container noch aktualisieren:

npm i -g cordova to update