import com.sun.star.uno

[MasterQ]

Moin allerseits,

ich bin absoluter java-Neuling, allerdings mit rund 40 Jahren Programmiererfahrung in verschiedenen Sprachen, zuletzt C#. Die Systax macht mir also keine Probleme.

Mein Ziel ist es, eine kleine Erweiterung für Libreoffice zu basteln und hangele mich grad durch ein Tutorial. Leider bleibe ich schon bei Schritt eins hängen.

import com.sun.star.frame.*;
import com.sun.star.lang.*;
import com.sun.star.uno.*;

public class tut02 {
        // TODO Auto-generated method stub
          public static void main(String[] args)
          {
            XComponentLoader loader = Lo.loadOffice();

            // load, manipulate and close a document

            Lo.closeOffice();
          } // end of main()
    }

}

Die Meldung besagt, dass die Namespaces der imports nicht aufgelöst werden können. Ich habe also eine oder mehrere Bibliotheken nicht eingebunden. Nun habe ich mir 2 Tage die Finger im Netz wund gesucht aber irgendwie keine Hinweise gefunden was ich da falsch mache. Ich glaube aus dem ein oder anderen herausgelesen zu haben, dass com.sun zumindest Standard wäre aber irgendwie doch nicht.

Kann mir jemand da etwas auf die Sprünge helfen, was ich wie nachinstallieren oder einbinden muss? Mir geht es jetzt weniger speziell um das Thema LibreOffice, sondern eher etwas allgemeiner wie das mit einen import in java angepackt werden muss.

Ich hatte es mit Eclipse und auch mit VS Code probiert.

Danke

Joachim

PS.: Ich habe openJDK-19 installiert

 

[mihe7]

Vielleicht hilft Dir https://www.java-forum.org/thema/classpath-ressourcen-ides-und-build-systeme.194131/ etwas weiter.

Was Dein Beispiel betrifft: das verwendet nicht nur die LibreOffice-Bibliotheken sondern zusätzliche Utitlity-Klassen, die sich allerdings bei mir nicht abrufen lassen (https://fivedots.coe.psu.ac.th/~ad/jlop/).

Ich hab das mal angetestet, anbei ein Maven-Projekt, das Du als Starter verwenden kannst (Achtung: das verbindet sich per TCP an einen laufenden Office-Server, dafür brauchst Du keine nativen Bibliotheken. Du musst also erst einen Office-Server starten. Das geht auch anders, dafür ist aber mehr Installationsaufwand notwendig).

 

[MasterQ]

Danke für die Hinweise.

In deinem Beispiel referierst du auch die com.sun.star.* Namespaces. Aber wo kommen die zugehörigen Bibliotheken her? In dem Verzeichnisbaum deines Beispielprojektes liegen sie nicht. Und in irgendwelchen XML oder anderen Dateien finde ich auch keinen Hinweis darauf.


Werden diese online automatisch nachgeladen oder wie funktioniert das? Kommen die aus dem sdk von Libreoffice? Und wenn ja, was muss ich da im Classpath eintragen?

Ich habe den schweren Verdacht, dass ich was grundlegendes falsch mache. Ich blicke grad gar nichts.

Dein Beispiel läuft bei mir nicht. Immerhin scheinen die Namespaces gefunden zu werden, denn am Ende heißt es:

Exception in thread "main" com.sun.star.connection.NoConnectException: java.net.ConnectException: Connection refused: connect
at com.sun.star.lib.connections.socket.socketConnector.connect(socketConnector.java:143)
at com.sun.star.comp.connections.Connector.connect(Connector.java:118)
at com.sun.star.comp.urlresolver.UrlResolver$_UrlResolver.resolve(UrlResolver.java:106)
at com.github.mihe7.librestart.Librestart.main(Librestart.java:28)

 

[MasterQ]

Ich habe noch etwas rumgespielt, auch mit verschiedenen IDEs. Einzig mit NetBeans habe ich es (fast) hinbekommen. Da gibt es eine Suchmaske und die findet org.LibreOffice, was dann com.sun.star etc beinhaltet.
Aber bei Eclipse oder Visual Studio code komme ich nicht weiter.

Bei NetBean erhalte ich

Exception in thread "main" java.lang.RuntimeException: Uncompilable code - Konstruktor für Any(<nulltype>) nicht geeignet
Konstruktor com.sun.star.uno.Any.Any(java.lang.Class<?>,java.lang.Object) ist nicht anwendbar
(Liste der tatsächlichen Argumente hat eine andere Länge als die der formalen Argumente)
Konstruktor com.sun.star.uno.Any.Any(com.sun.star.uno.Type,java.lang.Object) ist nicht anwendbar
(Liste der tatsächlichen Argumente hat eine andere Länge als die der formalen Argumente)
at com.jhx.mavenproject1.Mavenproject1.main(Mavenproject1.java:1)

 

[mihe7]

Aber wo kommen die zugehörigen Bibliotheken her? In dem Verzeichnisbaum deines Beispielprojektes liegen sie nicht. Und in irgendwelchen XML oder anderen Dateien finde ich auch keinen Hinweis darauf.

Schau mal in die pom.xml, da steht die Abhängigkeit zu

<dependency>
  <groupId>org.libreoffice</groupId>
  <artifactId>libreoffice</artifactId>
  <version>7.5.0</version>
</dependency>

Maven lädt automatisch aus dem zentralen Repository (https://mvnrepository.com/artifact/org.libreoffice/libreoffice/7.5.0) die für diese Bibliothek benötigten Abhängigkeiten herunter (wenn Du Dir das dort genannte POM anschaust, siehst Du, dass keine weiteren Abhängigkeiten genannt sind, also sollte das JAR https://repo1.maven.org/maven2/org/libreoffice/libreoffice/7.5.0/libreoffice-7.5.0.jar reichen - aber, wie gesagt: das macht Maven alles automatisch für Dich).

 

[mihe7]

Einzig mit NetBeans habe ich es (fast) hinbekommen.

Eigentlich sollte es reichen, das Projekt zu öffnen (ist ein Maven-Projekt) und neu zu bauen.

 

[M.L.]

rumgespielt...Uncompilable code

Passt die verwendete Java-Version ? Die gepostete pom.xml arbeitet mit Java 17 (kann man aber ändern):

..
<maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>..

Weiterhin kann man nur mit der Kommandozeile, Maven und Zielen arbeiten: ..\librestart> mvn deploy ( https://www.baeldung.com/maven-goals-phases ) Dort sieht man im Erfolgsfall auch wohin Inhalte heruntergeladen wurden (z.B. ...\.m2\repository\org\libreoffice\libreoffice\7.5.0 )

 

[MasterQ]

Passt die verwendete Java-Version ? Die gepostete pom.xml arbeitet mit Java 17 (kann man aber ändern):

..
<maven.compiler.source>17</maven.compiler.source>
        <maven.compiler.target>17</maven.compiler.target>..

OK, ertappt! Auf 19 umgestellt, und es compiliert durch. Was bleibt ist

Exception in thread "main" com.sun.star.connection.NoConnectException: java.net.ConnectException: Connection refused: connect

Das muss ich mir noch näher anschaun, siehe unten.

Maven lädt automatisch aus dem zentralen Repository (https://mvnrepository.com/artifact/org.libreoffice/libreoffice/7.5.0) die für diese Bibliothek benötigten Abhängigkeiten herunter (wenn Du Dir das dort genannte POM anschaust, siehst Du, dass keine weiteren Abhängigkeiten genannt sind, also sollte das JAR https://repo1.maven.org/maven2/org/libreoffice/libreoffice/7.5.0/libreoffice-7.5.0.jar reichen - aber, wie gesagt: das macht Maven alles automatisch für Dich).

Sowas hatte ich vermutet. NetBean bietet einem dafür ein Formular bei dem man die Namespaces eingeben kann und das entsprechende Paket wird dazu angegeben, das dann in der POM eingetragen wird. Deswegen hatte ich es auch weiter gebracht, als z.B. mit Eclipse.

Bei Eclipse habe ich keinen Ansatz wie das dort funktioniert.

Du musst also erst einen Office-Server starten.

dazu habe ich bisher nur was für Base (HSQLDB) gefunden. Gibt es ein gutes allgemeines HowTo?

Ich gebe zu, dass es mir schon sehr lange nicht mehr so schwer gefallen ist, in eine neue Thematik einen Fuß in die Tür zu kriegen.


Joachim

 

[mihe7]

dazu habe ich bisher nur was für Base (HSQLDB) gefunden. Gibt es ein gutes allgemeines HowTo?

Das ist einfach eine Befehlszeilenoption: https://wiki.documentfoundation.org...al_UNO#Starting_LibreOffice_in_Listening_Mode

Das Beispielprogramm erwartet allerdings, dass der Server auf Port 8100 läuft. Das liegt einfach daran, dass ich den Spaß via Docker mit dem Image https://github.com/hannesdejager/docker-libreoffice-api laufen habe lassen - und das startet LibreOffice mit der Befehlszeile

/usr/bin/libreoffice --headless --nologo --nofirststartwizard --accept="socket,host=0.0.0.0,port=8100;urp"

Wichtig ist dabei der accept-Parameter.

 

[M.L.]

Eclipse

File - Import - Maven - "Existing Maven Project" :


(ändert aber nichts an den fundamentalen Voraussetzungen: richtiger Port für Office, passende JRE,...)

 

[M.L.]

Lo.loadOffice(); ... Lo.closeOffice();

Die Maven-Vorlage lässt sich durchaus zum Herunterladen der Bibliotheken und Ändern des Quellcodes verwenden, dafür ist an anderen Stellen Hand anzulegen, z.B. beim Verwenden von "Lo.java": https://flywire.github.io/lo-p/install.html (-> 2., herunterladen, extrahieren, "Lo.java" (u.a.) inkludieren) (potentielle Quelle des Tutorials: https://flywire.github.io/lo-p/02-Starting_and_Stopping.html )

 

[MasterQ]

Ich hatte jetzt mal ein paar Tage Pause gemacht, um mich selbst zu resetten und von u.U. vorhandenen Verrennungen zu befreien.

Dein Beispiel, mihe7, läuft. Die Samlung aus dem Buch von fivedots läuft nicht. Die einzelnen Klassen sind heftig miteinander verwoben und es ist mir nicht gelungen, das aufzulösen. Die Sammlung stammt aus 2016 oder 2017 und einige Sachen sind dort schon als depricated gekennzeichet Vielleicht liegt es daran.


Was ich in diesem Thread noch abschließend fragen möchte, ist:

Wenn ich in Sourcecode Imports von Namespaces finde, wie kriege ich raus, aus welchem Repository oder Paket die stammen? Es wurde auf die Repository-Sammmlung MVNRepository hingewiesen. Aber dort findet man auch nur z.B. org.libreoffice aber nix zu com.sun.star.uno.

Auch wenn Maven das richtet, würde mich interessieren, wie es zu Fuß geht. Maven muss ja auch von den Namespaces auf die Repos rückschließen können.

 

[KonradN]

Maven muss ja auch von den Namespaces auf die Repos rückschließen können.

Nein, Maven interessiert sich nicht für Namespaces. Namespaces sind etwas, das nur auf der Java Ebene existieren und die dann für die Java Komponenten von Interesse sind. Diese bekommen aber dann einfach die jar Files in den classpath und schon kann der Classloader auch Klassen aus den Namespaces aus den jar Files ansprechen.

Ich kenne da auch keinen generellen Weg. Ich versuche immer, über die Seiten der Anbieter zu gehen oder eben einfach per Google zu suchen.
So kann man z.b. einfach nach "namespace com.sun.star.uno" suchen und findet dann direkt als ersten Treffer:

namespace uno

Es gehört also zu der OpenOffice API und es ist von Apache. Also kann man sich das dann in Ruhe ansehen, z.B. einfach mal Links auf die API module structure klicken. Und da findet sich dann direkt beim ersten Modul: "Contains the part of the API which belongs to the UNO core." und das sieht dann doch zielführend aus.

Sprich: Wenn man sich mit den Abhängigkeiten auseinander setzen muss, dann sollte man es direkt richtig machen und sich dann da richtig einlesen. Also hier wäre es dann wirklich, dass man sich die OpenOffice API von Grund auf anschaut.

 

[MasterQ]

namespace uno
Es gehört also zu der OpenOffice API und es ist von Apache. Also kann man sich das dann in Ruhe ansehen, z.B. einfach mal Links auf die API module structure klicken. Und da findet sich dann direkt beim ersten Modul: "Contains the part of the API which belongs to the UNO core." und das sieht dann doch zielführend aus.

Es ist kein Problem, irgendwelche Infos zur API zu finden.


Nur wie kommt man dahinter, dass man für den Zugriff auf com.sun.star.uno das Repo org.libreoffice einbinden muss. In allem was ich bisher gelesen habe, wird org.libreoffice nie erwähnt. Ich hatte den Code aus den Tutorials in mein neues Projekt einkopiert und die Fehlermeldung erhalten, dass com.sun.star.uno nicht aufgelöst werden kann. Und jetzt? Ich habe mir einen Wolf im Netz gesucht und keinerlei Verbindungen zwischen Namespace und Repo gefunden.

Füge ich in Netbean eine neue Abhängigkeit ins Projekt ein, kommt ein Formular hoch, in dem ich Suchen kann. Und bei Eingabe von com.sun.star.uno kommt ein Hinweis auf org.libreoffice, das dann von MVNRepository heruntergeladen und eingebunden wird. Also irgendwo ist diese Info vorhanden. Aber was mache ich, wenn nicht Netbean sondern z.B. Eclipse die IDE meiner Wahl ist/wird?

 

[KonradN]

Also ich kann Dir da keinen klaren Weg nennen. Ich kann Dir nur sagen, wie ich immer vorgehe.

Und ich gehe immer den Weg über die API selbst. Dabei ist es egal, ob Libreoffice oder OpenOffice (beide haben den gesuchten Namespace!)

Maven hat zwar prinzipiell auch eine Suche nach Namespaces (https://search.maven.com), aber das findet bei Suche nach Namespaces oft nichts. Wenn ich da nach dem Namespace suche, dann wird da nichts gefunden. Als Beispiel kann man den Namespace com.sun.star.uni nehmen. Das ist ein Namespace, der zum Beispiel bei org.openoffice:jurl vorhanden ist. Aber auch bei org.libreoffice:libreoffice.

Daher: Ich suche immer nach der API beim Anbieter. Das wäre hier im Thread LibreOffice (oder OpenOffice - das hat ja auch gleiche Wurzeln). Da suche ich dann auf mvnrepository.com z.B. nach libreoffice oder openoffice und schaue da dann in erster Linie auf die artefactIds. Und da ist halt das Ziel, die artefactId ausfindig zu machen, die da verwendet wird um da dann die einzelnen Pakete, die es gibt, näher ansehen zu können.

Damit bin ich bisher immer sehr gut gefahren und hier ist halt nur das Problem, dass die Dokumentation bei den APIs aus meiner Sicht nicht wirklich so ist, wie es meist gewohnt bin. Das macht es etwas schwerer und sorgt für deutlich mehr Einarbeitungszeit.

Das ist mein Vorgehen. Evtl. findet @mihe7 die Zeit, da noch sein Vorgehen zu nennen. Aber mehr kann ich da halt nicht beisteuern.

 

[KonradN]

und schaue da dann in erster Linie auf die artefactIds. Und da ist halt das Ziel, die artefactId ausfindig zu machen, die da verwendet wird um da dann die einzelnen Pakete, die es gibt, näher ansehen zu können.

Hier habe ich natürlich beim Schreiben gepennt. Ich achte auf die groupIds. Denn ich will schauen, ob ich den Anbieter selbst finde. Also org.libreoffice oder org.openoffice sind die beiden groupIds, un denen es einmal von OpenOffice und einmal von LibreOffice angeboten wird.

 

[mihe7]

Das ist mein Vorgehen. Evtl. findet @mihe7 die Zeit, da noch sein Vorgehen zu nennen.

Nichts anderes mache ich auch: erstmal beim Anbieter selbst schauen, ansonsten Suche via Google (maven und z. B. libreoffice). Wenn ich z. B. bei OpenOffice suche, finde ich https://wiki.openoffice.org/wiki/Uno/Java/MavenBundles, dann schaue ich mir auf mvncentral den Spaß wg. der Versionen an. Beispielsweise https://mvnrepository.com/artifact/org.openoffice/juh/4.1.2 -> 2015 -> WTF?!? Da gefällt mir doch https://mvnrepository.com/artifact/org.libreoffice/juh/7.5.0 (2023) schon besser

 

[Fabi123]

Hallo,
Kann es vielleicht daran liegen das es jurt,juh,ridl,unoil einzeln garnicht mehr gibt (also schon aber sind leer) und nun eine Dependency sind? https://mvnrepository.com/artifact/org.libreoffice/libreoffice/7.5.0

 

[mihe7]

Die Sammlung stammt aus 2016 oder 2017 und einige Sachen sind dort schon als depricated gekennzeichet Vielleicht liegt es daran.

Du kannst ja auch die alten Versionen via Maven einbinden. Dann nimmst Du halt die org.openoffice-Artefakte.

 

[MasterQ]

Auf alle Fälle ist das eine ziemliche Wurschtelei.

org.libreoffice habe ich eingebunden, trotzdem wird gemeckert, com.sun.star.comp.beans würde nicht gefunden. Alles deutet darauf hin, dass dieses beans vorhanden sein müsste. Heute morgen dann habe ich gesehen, dass es nicht mehr unter com.sun.star.comp liegt, sondern eine Ebene höher, also comp.sun.star.beans

Also straight forward ist anders!

Das Tutorial von fivedots ist eindeutig mittlerweile nicht mehr wirklich brauchbar. Seit den Tagen damals hat sich zur aktuellen Version 7.5 wohl doch einiges geändert. seufz

Ich bleib dran, mal sehen wie lange 😁

 

[Fabi123]

Hallo,
Ich glaub das hier wird auch benötigt: https://mvnrepository.com/artifact/org.libreoffice/officebean/7.5.0 Das besitzt com.sun.star.comp.beans und ist auf der Version 7.5.0

 

[MasterQ]

öhm, ja das ist sehr wahrscheinlich.

Yepp, das bringt mich weiter. Aber dennoch, ich bleibe an einer Depricated Meldung nach der anderen hängen. Da ist soviel was mit den aktuellen libs nicht vereinbar ist.

Ähnlich bei den Abhängigkeiten, ... urgs

 

[Fabi123]

Wo genau kriegst du die Fehler und was sagt der zu den Fehlern? Benutzt du Eclipse?

 

[MasterQ]

Ich hatte es mit folgenden IDEs probiert:

• Eclipse
• Netbeans
• IntelliJ
• Visual Studio Code

Schon in den Editoren wurde angezeigt, dass die im Tutorial angegeben Namespaces nicht aufgelöst werden konnten. Nachdem mir offenbart wurde, dass die fehlenden Bibliotheken als org.libreoffice laufen und auch noch OfficeBean benötigt wird, meckern die Editoren jetzt nicht mehr. Dafür kommen beim Versuch zu kompilieren Meldungen bzgl. abgekündigter (Depricated) Methoden. Einige Warnmeldungen sind im Quellcode schon unterdrückt aber nicht alle, so dass es so aussieht, als ob nach der Veröffentlichung des Tutorials noch einige weitere Methoden von LibreOffice abgekündigt wurden.

Aktuell sieht es so aus, als ob die mit dem Buch/Webseite bereitgestellten utils nicht mehr brauchbar sind, weil einfach zu viel nicht durchläuft und der Aktualisierung bedarf. Das übersteigt meinen Grad an Java Skills doch deutlich. Ich denke auch nicht, dass es Sinn macht, alle Warnungen abzuschalten. Ich will ja nicht mit aller Gewalt irgendwas zum Laufen kriegen, von dem ich nichts verstehe und von dem ich nicht ausgehen kann, dass beim nächsten Update noch alles geht.

Die Doku zu LibreOffice ist derart grottig, dass man ohne jahrelange Java-Erfahrung bzw. Programmiererfahrung mit LibreOffice speziell kaum Chancen hat da einigermaßen durchzusteigen. Das ist eine Doku von Profis an Profis und nicht für Einsteiger.

Und bei Java selbst bringt mich das Paket-Management bzw. die Auflösung von Abhängigkeiten an meine Grenzen. Aber es wird. So langsam finden meine Füße gripp und meine Kentnisse nehmen Fahrt auf. Wenn auch nicht so rasant wie erwartet.

 

[Fabi123]

Ahhh Jaa ich mag die LibreOffice Dokumentation ehrlich gesagt auch nicht 😅 Habe es aber mit Eclipse geschafft den Beispiel CellTexts.java von fivedots mit den Utils zum laufen zu bringen. Habe es hier hochgeladen und kannst es gerne ausprobieren vllt hilft es weiter.

 

[MasterQ]

Habe es aber mit Eclipse geschafft den Beispiel CellTexts.java von fivedots mit den Utils zum laufen zu bringen

Respekt!