Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Dazu Frage Nr. 1. : Es wird im Link unter non - modular/modular unterschieden. Worauf bezieht sich dieser Unterschied hier und was hat er für Auswirkungen?
Was mir aufgefallen ist, dass das setup augenscheinlich über new Project -> JavaFX ... beschrieben wird und nicht über eine mögliche Lösungen mit Maven.
Ich könnte es jetzt via trail & error versuchen, aber ich dachte es können bestimmt die erfahrenen Mitglieder hier, mir mögliche Fallstricke im Vorfeld nennen und was es noch im Falle zu beachten gibt!?
eine umwandlung von einem javafx projekt in ein maven projekt ist immer möglich, ansich nimmst du deine projekt box und legst sie in die maven box rein das ist immer möglich zb in eclipse machst du rechtsklick drauf und wandelst es in ein maven projekt um und fertig
Also ich werde da ehrlich gesagt aus dem Link den Du da gefunden hast, nicht ganz schlau. Da wird scheinbar einfach nur ein möglicher Weg genannt, wie man vorgehen kann.
Aber das sind zwei paar Schuhe aus meiner Sicht: Wie Du das Projekt aufbaust ist unabhängig von der SceneBuilder Integration in IntelliJ.
Du kannst also jederzeit einfach ein Maven Projekt mit JavaFX aufbauen. Das ist übrigens immer der Weg, den ich gehe. Neue Projekte erstelle ich eigentlich immer durch manuelle Erstellung einer POM (aus einer existierenden Datei). Das ist am einfachsten und schnellsten.
Und die Einbinsung des SceneBuilders in IntelliJ: Da ist eigentlich nichts zu machen. Du öffnest einfach eine fxml Datei und dann bekommst Du den Inhalt angezeigt. Unten kannst Du dann in Tabs auf die grafische Darstellung wechseln und das ist der SceneBuilder.
Beim ersten Mal läuft das auf einen Fehler - ihm fehlt der SceneBuilder. Oben bekommst Du dann ein Link zur Fehlerbehebung angezeigt -> Anclicken und IntelliJ lädt dann den SceneBuilder selbst runter.
Dann kommt der nächste Fehler: Die JavaFX Runtime fehlt Intellij, aber wieder gleiches Vorgehen: Link oben anklicken und IntelliJ lädt alles runter
==> Fertig, SceneBuilder ist im IntelliJ integriert.
Non Modular vs Modular: Ab Java 9 kennd Java Module. Non Modular bedeutet einfach nur, dass Du von dem System so wenig wie möglich nutzen willst und daher keine module-info.java erzeugst. Dann ist deine Applikation immer noch modular, aber alles ist in dem anonymen Modul.
Das bringt aber diverse Probleme mit sich, daher wäre mein Ratschlag, dass Du Dir das Modulsystem anschaust und damit vertraut wirst.
Ich fand die Getting Started Dokumentation von openjfx.io lange Zeit sehr gut. Aber leider musste ich feststellen, dass dies leider sehr begrenzt ist.Du kannst damit sehr gut starten, aber aus meiner Sicht kommt man früher oder später zu einem Punkt, an dem das nicht ausreicht und man dann das openjfx Plugin raus schmeisst um statt dessen andere Plugins (u.a. moditect) zu verwenden. Zumindest hatte ich hier keine Alternativen gefunden. Aber das ist etwas, auf das man dann kommt, wenn es soweit ist.
Neue Projekte erstelle ich eigentlich immer durch manuelle Erstellung einer POM (aus einer existierenden Datei). Das ist am einfachsten und schnellsten.
Also wenn Du selbst noch kein solches Projekt hast, dann muss man natürlich bei anderen Projekten "klauen".
Oder man generiert es selbst.
Die drei Möglichkeiten, die ich sehe (und bei denen ich zu der letzten Variante raten würde):
a) Man nutzt die IDE um sich irgend was generieren zu lassen. Geht, aber da kommt oft genug der größte Unsinn bei raus. So ist das Umwandeln eines Eclipse Projekts in ein Maven Projekt ein Garant für Schrott (Sorry, wenn ich das so hart formuliere, aber das meine Meinung. Erläuterung kommt weiter unten!) Aber die meisten IDE bieten auch einen Weg, ein sauberes, neues Maven Projekt zu erstellen. Man kann dann ein Archetyp auswählen und wenn man da org.openjfx auswählt, dann wird man das erhalten, was man auch bei Schritt b) erhalten würde. (Setzt aber voraus, dass man es findet. Bei IntelliJ wird man erschlagen von tausenden möglichen Archetypen....
Aber da beisst sich die Katze leider auch in den Schwanz, denn um den Befehl ausführen zu können, braucht man eine Maven Installation (die ich eigentlich ablehne bzw. als unnötig ansehe).
c) Man klaut bei anderen Projekten oder woanders. Ich finde hier das Forum z.B. auch eine gute Quelle. Wobei da die Stärke nicht die Erstellung eines POM sondern mehr die Anpassung ist, um Probleme zu lösen.
Ein Ort, bei dem Du "klauen" kannst: https://github.com/kneitzel/blog-javafx-series
Dort findet Du in 03 helloworld - maven ein kleines Maven Projekt für JavaFX, welches Dir ein erstes, minimales Projekt gibt, das das openjfx Plugin nutzt.
Was da auch dabei ist: Der Maven wrapper. Das ist ein Satz von Scripten (Windows und Unix/Mac) das dann aus .mvnw etwas startet, dass Maven herunter lädt und im Homeverzeichnis entpackt. Das ist besser als eine lokale Installation, denn jedes Projekt kann dann genau die Maven Version bekommen, für die es entwickelt wurde.
Das ist ein guter Start. Evtl. wirst Du aber an gewisse Limitierungen stoßen, die dann dazu führen, dass wir das Plugin raus werfen und andere Plugins einbringen (moditect + paar andere). Dazu kommen wir aber erst später - Es macht durchaus Sinn, erst einmal so klein anzufangen.
Nun aber noch zu der Erläuterung, wieso es Müll ist, ein bestehendes Projekt in ein Maven Projekt umzuwandeln (wie es das Eclipse bietet, bei IntelliJ weiss ich es nicht, denn sowas habe ich nie gewollt so dass ich da nie danach geschaut habe!):
Bei Maven gilt: Convention over Configuration
Das bedeutet, dass es für vieles einen Standard Weg gibt. An den sollte man sich halten und schon hat kleine, einfache Projekte, weil vieles nicht konfiguriert werden muss. Das fängt schon damit an, dass Java Files von Ressourcen getrennt sind. Test und Produktion sind getrennt. Du hast also src/main/java für Java Dateien, src/main/resourcen für Resource Dateien. Wenn Du ein Eclipse Projekt hast, dann hast Du einfach nur src. Ist ok, kann man auch mit Maven machen. Dann findet sich halt die Konfiguration, dass die Sourcen in src liegen und die Ressourcen sind auch in src aber alle java Dateien werden ausgeschlossen.
Und wo ist das Problem? Da geht es dann auch wieder zu Dingen, die man beim Clean Code beachtet:
- Auch die POM sollte übersichtlich sein und bleiben
- Man hat nicht das, was man erwartet. Einfaches Beispiel: Man kommt zu einem Projekt, sieht die pom.xml und was erwartet man dann?
Und so einfach wie diese einfache POM erst einmal war: Die Komplexität nimmt ja weiter zu: Denn wenn Du dann irgend etwas weiteres Konfigurierst (irgend welche weiteren Plugins und so), dann zieht sich so eine Anpassung ggf. weiter durch. Viele Dinge sind gerade am Anfang ein "copy & paste". Du willst irgendwas einbauen? -> eine kurze Suche: Plugin xyz macht das und es gibt sofort ein kleines Beispiel wie das anzuwenden ist.....
Das erklärt dann auch die typischen Threads: "Bei mir funktioniert etwas nicht. Meine POM ist <riesige POM voll mit solchen dubiosen Konfigurationen>" und dann fast immer die Antwort: "WTF, räum die POM auf, nimm am besten diese hier: <kurze, übersichtliche POM>" (Und das nicht von mir, weil ich hier eine seltsame Position vertrete sondern das kommt von Anderen hier )
Daher: Aus Eclipse Projekt ein Maven Projekt machen: Ja, jederzeit. Aber nicht mit einem Kopfdruck sondern in dem man eine saubere POM erstellt und die Dateien entsprechend verschiebt.
Edit: Das POM in dem blog von mir ist etwas alt und entspricht nicht dem Aufbau, wie ich ihn derzeit vertreten und vorschlagen würde. Aber es ist ein valider Anfang so wie er auch vermutlich erzeugt würde. Ich ziehe "Literale" aber in die Properties, so dass ich dann z.B. die ganzen Versionen und so in den Properties finde.
Ich hab nur noch ein kleines Noob Problem bevor ich anfangen kann es mal zu testen, bzgl. GitHub
Ich wollte mir gerade das Maven Projekt von dir ziehen. Allerdings habe ich es bisher immer so gemacht, dass ich über den grünen Code Button die URL kopiert habe und so in IntelliJ importiert habe. Wenn ich das aber jetzt bei deinem Repo mache, dann lade ich ja das komplette Projekt inklusive den ganzen anderen Kram ( Gradle etc.).
Wie kann ich nur das 03 helloworld - maven ziehen?
Git unterstützt das nicht. Github unterstützt aber auch svn und mittels svn wäre dies möglich: svn co https://github.com/kneitzel/blog-javafx-series/trunk/03%20helloworld%20-%20maven
Git unterstützt das nicht. Github unterstützt aber auch svn und mittels svn wäre dies möglich: svn co https://github.com/kneitzel/blog-javafx-series/trunk/03%20helloworld%20-%20maven
Okay. ich habs jetzt erstmal so gemacht, dass ich doch das komplette Repo geladen habe und dann aus dem maven project ein neues erstellt habe.
Hab gerade keine Lust mich den Git Kram auseinander zusetzen.
Soweit hat deine Erklärung von #3 problemlos geklappt.
Danke!
Ich werd jetzt erstmal bisschen rumtesten und versuchen mich zurecht zu finden.
Das einzige was ich an der Stelle noch kurz fragen will, weil ich die Verzeichnisstruktur nicht gleich verhauen will.
Ich habe das test.fxml einfach über new -> FMXLFile in dem helloworld Unterordner erzeugt. Das sollte doch aber eigentlich in die Ressourcen rein, nech? Allerdings gibts bei mir gar kein Ressourcen Ordner. Was muss ich tun, damits diesen gibt?
1. Du schreibst zu den Abhängigkeiten, dass du da die mvvmFx Lib benutzt und gibst auch einen Satz ( compile group: 'de.saxsys', name: 'mvvmfx', version: '1.8.0' ) an der in die build.gradle dependency Block rein soll. Bezieht sich die Versions Nr. auf die Java Version? und Wo finde ich den dependency Block bei maven?
2. Die Annotationen, vor allem das @InjectViewModel, geben ja einfach eine Referenz auf das Objekt. Also ist das dann quasi in dem Falle ein " Import" des models?
3. Die @FXML Annotationen sind quasi die Bekanntmachung an die FXML/GUI, ja?
4. Was hat es mit der initalize() Methode aufsich, bzw. was soll das mit der URL? das versteh ich überhaupt nicht
zu 2. Die Annotation sagt der genutzten mvvmfx Library, dass in diese Variable das ViewModel hinein soll.
zu 3. Die @FXML Annotations kommen vom FXMLLoader. Das ist ein Hinweis, dass in die Variable die Referenz von dem Element mit der fx:id mit dem Namen der Variablen.
zu 4. Es gibt einen Lifecycle mit mehreren Phasen. Den Konstruktor kennst Du ja bestimmt von Java. Das wird aber direkt nach der Erstellung aufgerufen und das reicht nicht. Denn die Klassen, die die Instanz erzeugen, machen ja noch weitere Dinge: Z.B. das Setzen der Variablen mit @FXML Annotation. Nun willst Du aber ggf. noch Dinge machen, nachdem diese Initialisierung von Außen erfolgt ist: Das ist die initialize Methode.
Und in dem Beispiel siehst Du, dass da einfach das Binding gesetzt wird.
Falls Du da noch paar weitere Abhängigkeiten einbaust erwischst Du evtl. noch Abhängigkeiten, die keine Moduldefinition haben. Da werde ich dir vermutlich noch eine neue POM ohne openjfx Plugin und mit moditect & co fertig machen dürfen. Ich bin so nach und nach dabei, das alles in einer Art Maven Referenz zusammen zu tragen, aber ich komme irgendwie nicht wirklich viel zu der Dokumentation.
Falls Du da noch paar weitere Abhängigkeiten einbaust erwischst Du evtl. noch Abhängigkeiten, die keine Moduldefinition haben. Da werde ich dir vermutlich noch eine neue POM ohne openjfx Plugin und mit moditect & co fertig machen dürfen. Ich bin so nach und nach dabei, das alles in einer Art Maven Referenz zusammen zu tragen, aber ich komme irgendwie nicht wirklich viel zu der Dokumentation.
Es gibt hier natürlich keine Pflicht! der Hinweis auf das moditect plugin ist ja schon ein guter Hinweis und falls es dann Probleme gibt, kann ich ja nochmal schauen ob ich es hinbekomme
Ja, das ist soweit richtig. Wobei ich mich gerade wundere: Das provided würde da aus meiner Sicht nicht hin gehören. Warum das so aufgeführt wurde, kann ich gerade nicht nachvollziehen.
Dieder Hinweis bedeutet, dass die Abhängigkeit nicht mit der Applikation mitgegeben werden soll. Die Laufzeitumgebung wird dies schon bereit stellen. Nur eben das ist so eigentlich nicht der Fall. Daher vorsichtshalber das <scope>provided</scope> raus löschen.
Bezüglich Moditect Plugin - da finden sich hier im Forum bestimmt auch Threads. Auch meine Varianten damit gehen streng genommen auf ein Beispiel zurück, dass @mrBrown einmal hier im Forum bereit gestellt hat als GitHub Link.
ich brauche mal bitte ein kleines troubleshooting.
Reminder: ich hatte aus @kneitzel s github das maven Projekt verwendet. Dazu hab ich ein paar Probleme die sich im wesentlichen dazu zusammen fassen lassen, dass ich
1. Probleme mit dem Refactoring der files habe. Soll heißen, ich wollte einfach die HelloWorld.java umbenennen. Jetzt meckert aber IntelliJ rum, dass es die Klasse nicht mehr findet, weil Sie natürlich in der POM noch die alten Namen haben.
Liegt wahrscheinlich an dem Namespace, was mich zur nächsten Frage bringt :
Ich habe jetzt in das helloworld package noch zwei andere Klassen reingehauen. Liegen bei IntelliJ am gleichen Ort wie HelloWorld.java
werden, aber rot angezeigt. Es meckert nichts und kompiliert auch noch, aber es scheint ja nicht korrekt zu sein?
Zusatzfrage:
Wenn ich eine neue Datei ins Projekt einfüge, werde ich immer gefragt ob ich das in kneitzels Github laden will. Wie kann ich das Projekt generell von kneitzels Github entkoppeln?
Da wäre erst einmal wichtig, das Du die dort angegebenen Daten richtig verstehst. Die mainClass Property enthält den Namen des Moduls (Also das, was in module-info.java als Name vergeben wird) und dann nach dem / das Package mit der Klasse.
Daher einmal prüfen: Was steht in der module-info.java? Und in welcher Klasse ist Deine main Methode?
Ich habe in neueren pom.xml das auch alles in die Properties gezogen, so dass da innerhalb der weiteren Struktur keine weiteren Dinge angegeben werden müssen. Das macht dann das eine oder andere einfacher.
Ich habe eine kleine JavaFX Anwendung "FileBrowser", welche ich zwar nicht wirklich weiter entwickle, da ich die App nicht mehr brauche, aber es dient mir als JavaFX Spielwiese was die POM angeht.
Da steckt jetzt einiges mehr mit drin, als für Dich wichtig ist. Aber man kann sehr schön erkennen, dass da sehr viel in die Properties gewandert ist.
Das ist dann auch eine Variante ohne das openjfx Plugin - statt dessen wird moditect genutzt um ein paar fehlenden Abhängigkeiten eine Modul-Definition unter zu schieben.
Und ich sehe gerade, dass da ppar typische Dinge fehlen:
a) Ich nutze eigentlich ein Plugin, dass beim Start nach neuen Versionen schaut und auf diese hinweist.
b) Es fehlt die statische Codeanalyse mittels PMD
c) Ich lege eigentlich auch noch minimale Versionen von maven fest und so ..
Also immer noch nicht das, was ich einem Kollegen geben würde aber es ist ein vernünftiger Anfang.
Evtl. noch ein Wort zu der moditect Variante: Moditect kann eine kleine Diva sein - wenn da mit den Modulen irgendwas nicht stimmig ist, dann neigt es dazu, bei den JavaFX Libraries rumzumotzen. javafx.xyzEMPTY hat keine Modul-info oder so ähnlich. Hintergrund dabei ist, dass die javafx Abhängigkeiten aus mehreren jar Dateien besteht:
javafx-xyz-version.jar --> Leeres jar hat nur ein Manifest das es als javafx.xyzEMPTY ausweist.
javafx-xyz-version-OS.jar -> jar für das jeweilige OS wobei OS linux, windows oder mac sein kann.
Das ist der einzige Grund, wieso ich nicht zu Moditect rate solange es nicht notwendig ist. (Mit dem mvvmfx wurde es leider notwendig bei mir.)
Ich hoffe, ich konnte Dir zum einen Deine Frage beantworten und Dir zum anderen aufzeigen, wie man sowas ggf. besser Strukturieren kann, damit man nicht zig Stellen in der POM anpassen muss bei Änderungen.
Danke erstmal. Die Struktur von deiner POM aus dem letzten Post ist wirklich besser. Ich werde es später mal versuchen anzupassen. Ich habs jetzt auch geschafft zu kompilieren nachdem ich alles umbenannt habe.
Allerdings sind die neu eingefügten Klassen und Interfaces immer noch rot dargestellt. Das kann ich mir auch echt nicht erklären. alle haben das gleiche package.
Wenn ich eine neue Datei ins Projekt einfüge, werde ich immer gefragt ob ich das in kneitzels Github laden will. Wie kann ich das Projekt generell von kneitzels Github entkoppeln?
Hat dazu moch wer ne Idee? Ich hab gestern Abend mal bisschen recherchiert, aber bin nicht wirklich fündig geworden. Das einzige was ein bisschen Sinn macht ist den branch zu mergen, aber da sollte letztlich das Projekt immer noch nicht von kneitzel gelöst sein. ?
Also bezüglich der Klassen, die rot dargestellt werden: Was genau wird rot dargestellt? Die Dateinamen werden in roter Schrift dargestellt? Das wird vermutlich sein, weil die Datei nicht in git hinzugefügt wurde.
Ansonsten einfach einmal genau beschreiben, was das Problem ist.
Wenn Du etwas per git herunter geladen hast, dann kannst Du einfach das .git Verzeichnis löschen. Dann wäre das Verzeichnis kein git Repository.
Also einfach in IntelliJ schließen, dann .git Verzeichnis löschen. Damit IntelliJ beim erneuten Öffnen nicht meckert, entweder:
- .idea Verzeichnis und alle *.iml Dateien löschen -> Dann wird IntelliJ das Maven Projekt neu laden und alles neu erzeugen.
- .idea/vcs.xml löschen - da drin speichert IntelliJ die Information, dass das Projekt in git verwaltet wird.
Aber wenn Du da nichts machst, dann wird da IntelliJ einmal meckern und du kannst es einmal bestätigen meine ich ...
Wenn Du etwas per git herunter geladen hast, dann kannst Du einfach das .git Verzeichnis löschen. Dann wäre das Verzeichnis kein git Repository.
Also einfach in IntelliJ schließen, dann .git Verzeichnis löschen. Damit IntelliJ beim erneuten Öffnen nicht meckert, entweder:
- .idea Verzeichnis und alle *.iml Dateien löschen -> Dann wird IntelliJ das Maven Projekt neu laden und alles neu erzeugen.
- .idea/vcs.xml löschen - da drin speichert IntelliJ die Information, dass das Projekt in git verwaltet wird.
Aber wenn Du da nichts machst, dann wird da IntelliJ einmal meckern und du kannst es einmal bestätigen meine ich ...
ICh werde jetzt mal langsam mit der View und dem ViewModel anfangen. Nur nochmal kurz dazu.
Ich habe ja jetzt mehrere Models, also die Card und Player Klasse und das Quiz interface.
Sollte man dann für Player und Card jeweils View und Viewmodel schreiben oder das zu einer verbinden?
gibts da ne best practise?
Also Model hast Du das Model der Applikation, also Card, Player, Quiz, ...
Wenn Du nun ein Fenster hast, hast Du für dieses Fenster dann ein ViewModel, d.h. das hält die Daten, die Du für das Fenster benötigst in der Form, wie Du es brauchst. Und die View hast Du dann natürlich auch für ein Fenster.
Wenn Du es nun weiter unterteilen möchtest, dann kannst Du da view / viewmodel auch für Teile schreiben. Das kann einen Bezug zu einem Model haben aber muss nicht. Das kann z.B. interessant sein für Dinge, die Du regelmäßig an diversen Stellen benötigst. Das würde ich aber am Anfang nicht machen. Das kannst Du machen, wenn Du mehr Erfahrung hast und dein Projekt größer wird.
)
