Writing an OpenOffice.org UNO service in Java with Eclipse

UNO is the component model of OpenOffice.org. It is a small application server integrated into the OpenOffice.org software whose services can be accessed either internally by macros contained in documents or externally by other applications. That way it is for example possible that an application loads a document in OpenOffice.org Writer, changes the formatting of the document and saves it.

Writing an UNO service in Java (C++ and other languages are possible as well but not treated in this post) means:

  • Define the functionality of the service in a language independant way by using the interface definition language of UNO (UNOIDL).
  • Write the implementation of the service by implementing the interface of the UNOIDL definition plus a few other standard interfaces that every UNO service is required to prepare.
  • Compile the UNOIDL specifications and Java classes in one JAR file and put this with the type database and the other files already described here into an .oxt file (of course you can add other things like macros that make use of the UNO service as well).
  • Deploy the service by loading the .oxt file into the Extension Manager of OpenOffice.org.

Chapter 2 of the OpenOffice.org developers manual explains this in all details. Fortunately there is a plugin for Eclipse whose wizard generates an Eclipse project with a complete skeleton for an UNO service. There is a tutorial for installation and usage of this plugin and I recommend from my own experience reading the tutorial and following it’s instructions step by step.

The plugin has some limitations though, so for Jitenize I had to do some manual changes to the project:

  • The plugin wizard lets you only define interfaces with simple or already defined data types. For Jitenize I needed my own record structures. I used the plugin wizard to define the functions of the service with simple data types, added a new UNOIDL description file containing the record structure and changed the function definition afterwards. Btw. adding a new UNOIDL file did not work, I always got the “NOT A UNOIDL CAPABLE FOLDER” error. But adding a simple text file with the .idl suffix worked and this file was compiled automatically with idlc like all other .idl files.
  • After changing the UNOIDL description of the service the parameters of the implementation function of the service of course needed to be changed as well. Here I recommend to read the sections called “Type mapping of xxx” in Chapter 2 of the OpenOffice.org developers manual, especially “Mapping of Interface Types”  explains very well how IN, OUT and INOUT parameters in UNOIDL are mapped to Java.
  • What I did not accomplish was to generate a complete .oxt file with the plugin. The showstoppers were the .jar files for the dictionary lookup that I had added to the project and that did not show up in the .oxt file. I finally gave up and wrote my own shell script that created the .jar file with all .class files needed and created an .oxt file with this .jar file and the other files that the plugin had created for the .oxt file. If you try the same thing make sure you add the .class files in the /bin and in the /build directory of the project’s work space to the jar file.