Eclipse Build path duplication entry

Hallo ich versuche gerademit Hilfe eines Tutorials javaFx für Eclipse einzurichten. Bekomme jedoch bei einrichtend diesen Error:
Build path contains duplicate entry: 'org.eclipse.fx.ide.jdt.core.JAVAFX_CONTAINER' for project 'JavaGUIprogramms'

Ich weiß allerdings nicht wie ich das fixen kann zumal es bei demjenigen im Video genauso funktioniert hat.

Hier der Link zum Video:

Danke schonmal für alle Antworten.
 
ok

1. e(fx)clipse ist scheiße
2. siehe erstens... man kann es nicht genug ausdrücken 🙂

ich lade mal eclipse runter und dann kann ich dir sagen was man machen muss

falls du eclipse genommen hast weil das das erste war was du gesehen hast kannst du auch intellij hernehmen
ich kann es dir für beide sagen wie du es zum laufen kriegst
 
openjfx.io hat eine Getting Started. Damit ist es trivial eine JavaFX Anwendung aufzusetzen. Wenn man auf Schmerzen steht, dann kann man da auch der Doku folgen und es rein in Eclipse machen...

Aber mein Tipp: Maven (oder von mir aus Gradle) nutzen. Das ist das einfachste überhaupt.

Schnellstart wäre z.B. einfach ein Startprojekt zu nutzen. Ich hätte dafür z.B.:

Das nutzt nicht das Plugin von openjfx aber es hat alles vorbereitet, was man braucht:
  • moditect um ggf. Abhängigkeiten eine Modulbeschreibung unter zu schieben
  • Erstellung Image (per Moditect, entspreicht dem jlink)
  • Aufruf von jpackage

Man bekommt also wirklich das, was man weiter geben möchte ...
 
Aber mein Tipp: Maven (oder von mir aus Gradle) nutzen. Das ist das einfachste überhaupt.
Das kann man gar nicht oft genug betonen.

Dieses Rumgeeiere mit irgendwelchen IDE-internen Käse ist für die Tonne. Das kann man machen, wenn man mal schnell was kleines ausprobiert, das keine Abhängigkeiten braucht, dann ist die Integration in die IDE ein klein wenig besser (schneller), wobei das heute nicht mehr ins Gewicht fällt.
 
Dieses Rumgeeiere mit irgendwelchen IDE-internen Käse ist für die Tonne.
naja ...
eclipse erstellt wenn man ein javafx projekt erstellt erstmal ein projekt das nicht funktioniert
e(fx)clipse macht irgendwas was niemand weis was es darstellen sollte und funktioniert auch nicht out of the box
wenn man ein maven projekt erstellt werden auch einstellungen getroffen dass man nichts mehr machen kann

sogar almasb von FXGL erklärt wie man mit maven ein FXGL projekt in eclipse erstellt und betont dass das normale maven projekt nicht funktioniert (out of the box)
man msus ein java projekt erstellen und das in maven umwandeln

der satz mit intellij ist eher gemeint "hier funktioniert es out of the box" ... man hat keinen bock auf stunden lang mit den settings zu kämpfen um es zum laufen zu kriegen

eclipse ansatz wäre
1. java projekt
2. umwandeln in maven
3. dependencies hinzufügen
4. maven compiler plugin konfigurieren
5. javafx plugin konfigurieren

und bei intellij
1. javafx projekt erstellen

dann hast du dasselbe... aber er macht sein erstes maven bzw javafx projekt.. rate mal was er als "funktioniert" einstuft...
 
sogar almasb von FXGL erklärt wie man mit maven ein FXGL projekt in eclipse erstellt und betont dass das normale maven projekt nicht funktioniert (out of the box)
man msus ein java projekt erstellen und das in maven umwandeln
Wie bitte? Was ist ein "normales maven projekt" und was funktioniert nicht? Aber solche Aussagen sind extrem dubios.

Und der Ratschlag, in Eclipse in Java Projekt zu erstellen und dieses in ein Maven Projekt umzuwandeln ist mit das Schlimmste, das man machen kann. Vor allem: Was für magische Dinge passieren da, so dass es dann funktioniert aber das "normale" Maven Projekt nicht?

eclipse ansatz wäre
1. java projekt
2. umwandeln in maven
3. dependencies hinzufügen
4. maven compiler plugin konfigurieren
5. javafx plugin konfigurieren
Nein, wie ausgeführt: Das ist Müll.

und bei intellij
1. javafx projekt erstellen
Das habe ich mir noch nicht im Detail angesehen. Da hat sich ja bei den Projekten einiges getan in den letzten Versionen. Mag sein, dass da ein brauchbares Projekt bei raus kommt.

Aber: Warum kann man da nicht einfach ein vernünftiges Maven Projekt nehmen?

Aber egal, was ma macht: openjfx.io sollte da doch der erste Anlaufpunkt sein. Und da ist ein Getting Started. Dem kann man folgen. Da wird auch im Detail erklärt, was man benötigt. Damit kann man einen guten, schnellen Start bekommen, der funktioniert.

Aber bei den Maven Einführungen, die ich immer wieder geben darf für duale Studenten und junge Entwickler, die zu uns kommen:
  • Bei Maven gilt Convention over Configuration. Man sollte sich an die Konventionen halten, die da gelten (Und an die sich der Eclipse Weg oben explizit nicht hält!)
  • Maven hat den Vorteil, dass das eine Textdatei ist - einfaches Copy & Paste ist sehr einfach.
Die beiden Punkte zusammen sorgen dafür, dass ich da immer das Lied der Prinzen bringe: Das ist alles nur geklaut.

We starte ich ein neues Projekt?
a) Wenn es einen Generator gibt (Spring initializr oder start.vaadin.com), dann ist der eine Option (Bei mir nur für Tests - ich mag deren Parent Projekte nicht!)
b) Ich kopiere mir das einfach. Das für JavaFX habe ich ja bereits genannt.

Wobei das Copy & Paste auch bei AddOns sehr gut geht. Da habe ich meine Kopiervorlagen. Will da schon lange mal ein maven cheat sheet fertig machen aber da finde ich derzeit keine Zeit zu.
 
@yfons123, ich meinte IDE-interne (oder an die IDE angepasste) Buildsysteme. Die hatten durchaus ihre Daseinsberechtigung und z. T. mag das auch heute noch gelten.

Ich setze vorwiegend NetBeans ein. NB hat schon früh Ant verwendet, allerdings eben mit Hilfe von Plugins an NB angepasst. So lange man sich in NB bewegt (und das möglichst alleine) und kein Problem damit hat, sich mit irgendwelchen Abhängigkeiten rumzuschlagen, funktioniert das ganz hervorragend. Ivy wurde nicht verwendet (keine Ahnung, wie das heute ist, mit Ant schlage ich mich seit über 10 Jahren nicht mehr herum). Die Einstellungen des Projekts werden in .properties und .xml gespeichert und zumindest die .properties von den den Ant-Build-Scripts verwendet.

Funktioniert, bist halt an NB gebunden. Warum will man sich heute noch so etwas antun?!?
 
@yfons123, ich meinte IDE-interne (oder an die IDE angepasste) Buildsysteme. Die hatten durchaus ihre Daseinsberechtigung und z. T. mag das auch heute noch gelten.

Ich setze vorwiegend NetBeans ein. NB hat schon früh Ant verwendet, allerdings eben mit Hilfe von Plugins an NB angepasst. So lange man sich in NB bewegt (und das möglichst alleine) und kein Problem damit hat, sich mit irgendwelchen Abhängigkeiten rumzuschlagen, funktioniert das ganz hervorragend. Ivy wurde nicht verwendet (keine Ahnung, wie das heute ist, mit Ant schlage ich mich seit über 10 Jahren nicht mehr herum). Die Einstellungen des Projekts werden in .properties und .xml gespeichert und zumindest die .properties von den den Ant-Build-Scripts verwendet.

Funktioniert, bist halt an NB gebunden. Warum will man sich heute noch so etwas antun?!?

In meinem Fall arbeite ich mit Netbeans, Build, Tests und Release laufen aber auf einem Linux-Server (bzw. einige Tests noch auf einem Windows-Server). Also muss ich mich schon hin und wieder mit ANT rumschlagen 🙂

Probiere auch gerade Maven aus, allerdings hab ich damit noch nicht viel Erfahrung und weiß auch (noch) nicht, wie man's abseits der IDE vernünftig einsetzen kann.
ANT ist zwar schwerfällig, aber insgesamt hat man halt doch viele Möglichkeiten, da es zu mehr als nur zum Build verwendet werden kann, z.B. zum Ausführen von Scripten. Z.B. wird für an die hundert Verzeichnisse mit Konfigurationen jeweils eine Ausgabe erstellt und mit der jeweiligen Referenzausgabe verglichen, ob immer noch das Gleiche rauskommt.
 
Probiere auch gerade Maven aus, allerdings hab ich damit noch nicht viel Erfahrung und weiß auch (noch) nicht, wie man's abseits der IDE vernünftig einsetzen kann.
Maven funktioniert abseits der IDE genauso wie in der IDE. NetBeans zeigt Dir beim Build ganz oben auch die Befehlszeile an. In der Regel:
Code:
Projekt kompilieren, testen, bauen und ins lokale Maven Repository stellen (wichtig, wenn es eine Abhängigkeit anderer Projekte ist)
mvn install

Projekt bauen, z. B. das jar
mvn package

Projekt testen
mvn test

Projekt kompilieren
mvn compile

Projekt säubern
mvn clean
Die Targets sind auch kombinierbar: mvn clean install dürfte NB bei einem Clean & Build ausführen.

ANT ist zwar schwerfällig, aber insgesamt hat man halt doch viele Möglichkeiten, da es zu mehr als nur zum Build verwendet werden kann, z.B. zum Ausführen von Scripten.
Das ist richtig, wobei es für Maven entsprechende "Plugins" gibt (in Maven ist alles ein Plugin).


Z.B. wird für an die hundert Verzeichnisse mit Konfigurationen jeweils eine Ausgabe erstellt und mit der jeweiligen Referenzausgabe verglichen, ob immer noch das Gleiche rauskommt.
?!? Das hört sich für mich nach einem Test an. Apropos: Maven führt standardmäßig Tests aus, das kann man in NB deaktivieren und auf der Befehlszeile mit dem Schalter -DskipTests
 
?!? Das hört sich für mich nach einem Test an. Apropos: Maven führt standardmäßig Tests aus, das kann man in NB deaktivieren und auf der Befehlszeile mit dem Schalter -DskipTests
Richtig, ist auch einer. Neben Unit-Tests werden auch e2e Tests durchgeführt, ebenfalls gesteuert über das ANT Script, wie der Rest ausgelöst über die yaml.
 

Zurück
Oben