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.
ich hab folgendes Problem. Wenn ich eine neue Maven dependency in die pom.xml reinschreibe dann erkennt Intellij das nicht und ich muss jedes mal per "File/Invalidate Caches/invalidate and restart" erzwingen, dass Intellij einmal zu geht und dann erst beim erneuten aufmachen klappt es meistens.
Jetzt kommt noch hinzu, dass ich das https://mvnrepository.com/artifact/opencv/opencv/4.1.1 gerne einbinden würde, aber das wird leider nicht gefunden. Ich hab die dependency einfach ganz stumpf in die pom.xml kopiert mehr nicht.
Ich vermute, dass es daran liegt, dass es nicht in dem Central repository liegt. Aber was genau ich jetzt tun muss ist unklar.
Die erste Frage wäre ggf, wie Du die pom.xml anpasst: Aus IntelliJ oder extern? Wobei das nicht ganz so wichtig ist, denn IntelliJ sollte erkennen, wenn eine Datei extern verändert wurde.
Generell werden Änderungen an der pom nicht sofort übernommen (so man dies nicht eingestellt hat). Wenn Änderungen an der pom.xml vorgenommen wurden, dann blendet IntelliJ per default einen kleinen Button innerhalb des Editor-Fensters ein im Bereich der oben rechten Ecke. Darauf kann man zum neu laden der pom klicken. (Der Button sieht aus wie ein kleines m mit zwei entgegengesetzten Pfeilen in Kreisform oder so)
Ansonsten hast Du auch die Möglichkeit, über das Maven Toolfenster (wird in der Regel recht mit angezeigt - da solltest Du einen "Tab" Maven finden). So das maven Toolfenster nicht geöffnet ist, erreichst Du es über View -> Tool Windows -> Maven. Im maven Fenster hast Du dann auch wieder den reload Knopf.
Bei Problemen kann es manchmal Sinn machen, auf der Kommandozeile zu prüfen, ob aus Maven Sicht alles ok ist. Wenn im IntelliJ Projekt irgendwas zerschossen ist, ist es am einfachsten, einfach ein neues zu generieren (also .idea Verzeichnis und alle iml Dateien löschen). Aber das ist nur sehr selten notwendig nach meiner Erfahrung (Aber eine Problematik, die auch bei anderen IDEs auftreten kann, so ich das richtig beobachtet habe).
Bezüglich weiterer Repositories kann ich nur empfehlen:
Da wird dies recht gut beschrieben. Ich würde also einfach empfehlen, in dem pom mittels repositories/repository das Repository einzutragn. Die URL bekommst Du ja, wenn Du in Deinem Link auf das Repository clickst (Das blau hinterlegte EBIPublic). id / name kannst Du frei vergeben.
Nur um da etwas mehr als nur das "Nein" zu sagen:
Wenn man Maven als Build-System nutzt, dann greift IntelliJ natürlich auch auf Maven zu und die Abhängigkeit gehört in die pom.xml.
Und dann gibt es natürlich auch kein Gradle File. Ein Gradle-File gibt es nur dann, wenn man auch Gradle als Build System benutzt.
IntelliJ selbst hat ansonsten sein eigenes Projektfile und Format, welches man nutzen kann. Es erkennt aber auch andere Build-Systeme und kann auf diesen basieren (Maven, Gradle, Ant, ...) Wenn man mit IntelliJ auf andere Projektformate zugreift, dann macht es z.B. Sinn, die IntelliJ Dateien aus der source Verwaltung raus zu halten (.idea Verzeichnis, *.iml Dateien, ....), Denn wenn das IntelliJ Projekt (Das es auf Basis des eigentlichen Projekts auch geben wird) irgend welche Inkonsistenzen aufweist, dann kann es sinnvoll sein, di einfach zu löschen und dann IntelliJ das Projekt neu öffnen zu lassen. (Das gilt übrigens für alle IDEs. Das habe ich auch schon bei Eclipse und Netbeans erlebt!). Erkennbar ist sowas, wenn das Build in der IDE nicht durchläuft, aber auf der Kommandozeile alls sauber läuft.
Dann schau dir den link von ihm an. Was hat er angeklickt Gradle. Also will er es auch benutzen.
Wenn er ein anderes build System unter Intelli nutzten will muss er auch die dependency in diesen Format machen und mich im Gradle Format. In der XML.
Da nützen alle Erklärungen nicht viel.
Der Link enthält keinerlei Informationen über das gewählte Build-System (sieht man an dem Link ja auch). mvnrepository merkt sich aber, was man selbst als letztes ausgewählt hatte, und zeigt es danach standardmäßig an.
Hallo, leider klappt es immer noch nicht d.h. nachdem von Hand hineinschreiben des repository und dem reloaden des Maven projects kommt die Fehlermeldung: "cannot resolve opencvpencv:4.1.1".
Ich kopiere jetzt einfach meine pom.xml mal hier rein:
Okay, danke. Leider geht es direkt mit dem nächsten Problem weiter. Wenn ich teste ob alles funktioniert mit einem Minmalbeispiel an Code bekomme ich zur Laufzeit einen Fehler und zwar:
" Exception in thread "main" java.lang.UnsatisfiedLinkError: no opencv_java451 in java.library.path: ..."
Java:
System.out.println("OpenCV configuration simple test:");
System.loadLibrary(Core.NATIVE_LIBRARY_NAME);
Mat m = Mat.eye(3,3, CvType.CV_8UC1);
System.out.println("OpenCV matrix = " + m.dump());
So update, leider sehe ich keine editier Funktion für meinen Beitrag #16.
Java:
System.out.println("OpenCV configuration simple test:");
nu.pattern.OpenCV.loadShared();
System.loadLibrary(org.opencv.core.Core.NATIVE_LIBRARY_NAME);
Mat m = Mat.eye(3,3, CvType.CV_8UC1);
System.out.println("OpenCV matrix = " + m.dump());
Gibt zwar die Matrix wie gewünscht aus, aber davor noch reichlich Fehlermeldungen:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by nu.pattern.OpenCV$SharedLoader (file:/C:/Users/****/.m2/repository/org/openpnp/opencv/4.5.1-2/opencv-4.5.1-2.jar) to field java.lang.ClassLoader.usr_paths
WARNING: Please consider reporting this to the maintainers of nu.pattern.OpenCV$SharedLoader
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Irgendwie hab ich in Erinnerung das Maven die Sache vereinfachen sollte...
Das sind erst einmal nu Warnungen und die hängen nicht mit Maven zusammen. Die kommen von Java zur Laufzeit, denn Du nutzt Java 9 oder später (In der pom.xml ist 11 vorgegeben) und damit hast Du Module. Und da müssen Zugriffe entsprechend vorgegeben werden. So ein "reflective access" müsste erlaubt werden über eine Angabe, dass eben java.lang.ClassLoader für das OpenCV Modul geöffnet wird.
Die Warnung könnte man los werden per:
- --add-opens Parameter um dann dies entsprechend vorzugeben. Der Pfad könnte problematisch sein, denn vermutlich wird OpenCV noch ein anonymes Modul sein ... das liesse sich dann auch noch beheben aber das wird dann ein kleiner Rattenschwanz. (Daher die Empfehlung, die einfach nur sagt: Hau das den Entwicklern um die Ohren!) (Hier evtl. auch noch --illegal-access=permit angeben, um noch weitere Stellen zu finden!)
- --illegal-access=permit dürfte die Warnung einfach unterdrücken - aber halt mit der Gefahr, dass es irgendwann nicht mehr geht.
Das wäre so auf die Schnelle meine Sichtweise darauf.
damit hast Du Module. Und da müssen Zugriffe entsprechend vorgegeben werden. So ein "reflective access" müsste erlaubt werden über eine Angabe, dass eben java.lang.ClassLoader für das OpenCV Modul geöffnet wird.
Wobei das nur indirekt mit Modulen zusammen hängt, das sind ja Zugriffe die auf guten Gründen nicht „einfach so“ möglich sind, sondern explizit freigegeben werden müssen.
Die Warnung könnte man los werden per:
- --add-opens Parameter um dann dies entsprechend vorzugeben. Der Pfad könnte problematisch sein, denn vermutlich wird OpenCV noch ein anonymes Modul sein ... das liesse sich dann auch noch beheben aber das wird dann ein kleiner Rattenschwanz. (Daher die Empfehlung, die einfach nur sagt: Hau das den Entwicklern um die Ohren!) (Hier evtl. auch noch --illegal-access=permit angeben, um noch weitere Stellen zu finden!)
- --illegal-access=permit dürfte die Warnung einfach unterdrücken - aber halt mit der Gefahr, dass es irgendwann nicht mehr geht.
Ah, ok. Das hatte ich mir so gut noch nicht angesehen. Danke für die Info.
(Ich muss zugeben, dass ich so Libraries, die es in fast 4 Jahren nicht geschafft haben, entsprechend zu reagieren, auch nicht einsetze. Also unabhängig von diesem Fehler - auch generell bei fehlenden module-info bekomme ich Bauchschmerzen... (Wobei ich das schon vor Java 16 hatte. Java 11 ist Sept. 2018 raus gekommen und ab Mitte 2019 hatte ich dann schon kein Verständnis mehr für Libraries, die da nicht reagiert haben. Das ist in meinen Augen schon eine recht klare Aussage bezüglich: "Wechsel doch bitte zu einer Alternative". Ja, damit lehne ich mich stark aus dem Fenster und den muss man nicht folgen ... )
(Ich muss zugeben, dass ich so Libraries, die es in fast 4 Jahren nicht geschafft haben, entsprechend zu reagieren, auch nicht einsetze. Also unabhängig von diesem Fehler - auch generell bei fehlenden module-info bekomme ich Bauchschmerzen... (Wobei ich das schon vor Java 16 hatte. Java 11 ist Sept. 2018 raus gekommen und ab Mitte 2019 hatte ich dann schon kein Verständnis mehr für Libraries, die da nicht reagiert haben. Das ist in meinen Augen schon eine recht klare Aussage bezüglich: "Wechsel doch bitte zu einer Alternative". Ja, damit lehne ich mich stark aus dem Fenster und den muss man nicht folgen ... )
Die Warnungen gibts nicht wegen fehlender module-info, sondern weil Dinge genutzt werden, die zur internen API gehören, die lassen sich ganz bewusst nicht anders nutzen
Manche Dinge lassen sich anders nicht nutzen, je nachdem was die Lib machen soll.
intern laden beide Befehle die native Lib, beide etwas unterschiedlich, da sich ab Java 11 intern was geändert hat – wie und was und warum dürfte für die meiste Anwender aber wirklich uninteressant sein
kannst du zB im local storage deines Browsers angucken
