Schlagwort: JDK

Radikalschnitt

Die letzten Wochen standen bei mir ganz im Zeichen sehr vieler Schulungstage. Zuerst im Rahmen mehrerer Fachinformatikerausbildungen zu Python und MySQL, aber die letzten 3 Wochen komplett zu Java und JavaFX/OpenJFX. Dabei ging es bei purem Java um eine „Werkstatt“ im Rahmen der Fachinformatikerausbildung, bei der noch mit Swing gearbeitet wurde.

Bei dem Kurs zu JavaFX habe ich hingegen professionelle Java-Entwickler einer Berliner Behörde geschult, die vorher bei einem anderen Trainer einen Kurs zu Maven gemacht hatten und danach eben noch JavaFX kennenlernen sollten. Zum Teil hatten die aber auch schon vorher mit JavaFX gearbeitet.

Der JavaFX-Kurs war bereits früher angesetzt gewesen, aber der
eingeplante Trainer war ausgefallen und ich habe den Kurs mit einem neuen Termin kurzfristig übernommen. Die beiden Tage habe ich zwar recht schwer untergebracht und eigentlich war ich bereits so ausgelastet, dass ich im Grunde keine Termine mehr annehmen wollte. „Radikalschnitt“ weiterlesen

Preisexplosion beim Raspi

Ich muss zugeben, dass ich mir lange keine Preise für Hardware angesehen habe. Und schon gar nicht für den Raspberry Pi. Hin und wieder krame ich meinen alten Raspi der Version 1 raus und experimentiere damit rum. Aber die Version 1 ist wirklich so schwach auf der Brust, dass man damit eigentlich nur testen kann, welche Minimalhardware für gewisse Dinge notwendig ist und dabei braucht man viel Zeit und Geduld, bis die Programme starten bzw. fertig sind. Und wirklich nützliche Anwendungen habe ich in dem Bereich wenig gefunden, weil ich keine Hardwaresteuerung programmiere. Einzig die Ausführung von einem Python-Skript zur Spamabwehr ist derzeit eine produktive Anwendung des kleinen Raspi. Aber obwohl ich immer noch unter massivem Spambeschuss stehe, haben sich mittlerweile wohl die Antispam-Cloud-Dienste und die internen Spam-Abwehrmechanismen auf die neue Art des Spams eingestellt, die vor einigen Wochen wie eine Schlammlawine durchs Netz gewalzt ist. Der Raspi hat also als Torwächter wieder weniger zu tun. Bei einer anderen Anwendung hat aber die extrem schwache Hardware die Hürden nicht geschafft. Ich wollte für die kommende Cordova-Vorlesung, die ich an der TH Bingen ab übernächster Woche halte, ein Linux-System so konfigurieren, dass Cordova-Android-Apps kompiliert und nach Möglichkeit auch in einem Emulator (oder zur Not auf einem per USB angeschlossenen SmartPhone) ausgeführt werden. Da für Cordova eine ganze Reihe an recht alten Bibliotheken (JDK 8) auf der einen Seite und den elend vielen Ressourcen im Fall von Android auf der anderen Seite verlangt werden, ist meine Workstation nicht passenden konfiguriert – von meinem Matebook mit der kleinen SSD ganz zu schweigen. Und ich habe keine Lust, nur für die Vorlesung meine gesamten Konfigurationen durcheinander zu bringen und zig Sachen da zu installieren, die ich sonst nicht mehr brauche.

Zwar habe ich einen passenden Docker-Container noch von der letzten Vorlesung vorbereitet und auf den neusten Stand gebracht und auch mein altes Terra-Notebook hat Cordova sogar mit Visual Studio verfügbar (das geht maximal bis Visual Studio 2017 und das habe ich aus dem Grund auch noch auf dem alten Notebook gelassen). Aber unter meinen Linux-Systemen klappt die Installation von Cordova und den Android-Ressourcen nicht so richtig. In dem parallel auf dem alten Notebook installierten Linux ist irgendwas zerschossen und ich kann gar keine Aktualisierungen vornehmen. Das muss ich vermutlich komplett neu aufsetzen. Und bei den virtuellen Maschinen habe ich sowohl bei VM Ware als auch VirtualBox eine Reihe von anderen – und ganz verschiedenen – Problemen. Alles nix Tragisches, aber es kostet Zeit und wenn ein Problem gelöst ist, kommt das nächste. Unbefriedigend und es raubt Zeit.

Da kam mir die Idee, entgegen meiner bisherigen Planungen vielleicht doch einen neuen Raspi zu kaufen und den als Linux-System ins lokale Netz zu hängen und je nach notwendigem Ziel immer wieder neu aufzusetzen. Also so eine Art Hardware-Docker-Container-VM-Ersatz. Ich hatte für den ersten Raspi so um die 35 – 40 EUR ausgegeben, bin mit der Erwartung gerade auf die Suche gegangen und fast vom Glauben abgefallen. Die wollen ja teils weit über 200 EUR für die Platine mit ein bisschen Krimskrams dazu. Ne, wirklich nicht. Das hat ja gar nichts mehr mit der ursprünglichen Idee einer möglichst billigen Platine zu tun. Ich schaue mal weiter oder vielleicht gebe ich doch alternativen Platinen eine Chance, bei denen nicht noch zusätzlich ein Hype die Preise hochtreibt. Oder lasse es.

Derzeit kann man wohl weder Sprit bzw. Öl als auch Hardware kaufen. Benzin muss leider ab und zu sein (auch wenn ich weniger fahre und zudem wenn möglich auf das Rad oder eBike umsteige), aber Hardwarekauf kann verschoben werden, bis die Preise wieder normal sind.

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.

Java 16 ist da

Jetzt lerne ich JavaDie Version 16 von Java wurde gerade freigegeben. Seit der Einführung von Java 10 im Jahr 2018 verfolgt Oracle einen halbjährlichen Release-Plan. Damit soll man schneller auf Neuerungen im IT-Umfeld reagieren können. Ich persönlich finde die permanenten neuen Versionen allerdings nervig bzw. lästig. Die jeweiligen Neuerungen sind oft nur unter der Oberfläche, eher von kleiner Natur oder werden groß angekündigt und dann doch nicht implementiert. Das habe ich oft genug bei den letzten Versionen mitbekommen.

Aber sei es drum – auch wenn ich mich immer noch als Fan von Java sehe (vor allen Dingen den frühen Versionen), mache ich mit Java die letzten Jahre nicht mehr wirklich viel. Hin und wieder ein paar Online-Training für LiL (LinkedIn Learning) oder das Buch „Jetzt lerne ich Java“ von MuT. Aber irgendwie hat Java für mich ein wenig seinen Reiz verloren und auch die Anfragen für Schulungen oder Projekte im Java-Umfeld haben bei mir exorbitant abgenommen. Java fällt bei mir mittlerweile vor allen Dingen bei Schulungen zugunsten von Python fast komplett hinten runter. Was erstaunlich ist, denn Java war für viele Jahre neben clientseitiger Web-Programmierung meine Hauptsäule.

Was zu dem Fazit führt, dass ich gerade für April eine Java-Einzelschulung angenommen habe. Logisches Fazit, oder? 🙂

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