Non-code extensions

Basic Principles

The OpenOffice.org extension deployment concept based on UNO packages is not limited to code, it also allows to install other things like templates, autotexts etc. in handy packages. Here's a short explanation how this basically works. UNO packages are more or less zip containers with some additional data and meta data describing its content. If such a package contains a UNO component (written in Java, C++ or Python) it also provides a registry file for the UNO service(s) implemented by the component and probably another one for new UNO types used and defined by it. UNO packages can be deployed by the built-in Package Manager GUI (“Tools – Package Manager”) or by the command line tool “unopkg” that is located in the OOo program folder. The latter also allows to deploy a package not only for a single user but all of them by using the “--shared” parameter. When a package is installed its content is copied to some well defined though private places below “share/uno_packages” or “user/uno_packages”, depending on the scope of the package installation (whole installation or single user). When now OpenOffice.org uses its Service Manager to look for available UNO services it will include the service registry (services.rdb) not only in its program directory but also all registry files inside the “uno_packages” folders. Installing and removing components is done by adding or removing packages with unopkg, the global registry files are not touched at all.

Extendable Architecture of OpenOffice.org

The ConfigManager of OpenOffice.org has the same ability to scan an extendable set of folders and so components can extend or change the OpenOffice.org configuration in the same way, just by providing the necessary schema (xcs) or data (xcu) files inside the package. Of course you can even create packages that contain only configuration files but not any code components. This way it's possible to customize OpenOffice.org by handy packages. We could have extended other components inside OpenOffice.org that retrieve content from files (e.g. the component that manages document templates or the component for autotexts) in the same way, but we decided to reuse the already available capability of the ConfigManager and utilize it for other purposes. The idea is to make the list of folders to scan for content a configuration item (we call this a “multipath”) that can be extended by packages. This looks similar to the old feature that such pathes can be changed in “the Options” Dialog, but it's much easier to use and handle. It's easier especially for administrators that couldn't use the dialog and instead had to edit the configuration files by hand each time they deploy a new installation. So beginning with OpenOffice.org 2.0.4 the configuration schema for paths has changed considerably. We also kept this old feature for compatibility reasons and migrate its settings to the new data. If you look on the “Path” settings in the “Options” Dialog in OOo2.0.4 you will notice that not all parts of the multipaths are shown here. The reason is that the dialog shouldn't expose anything to the user that is not under his control, thus you don't see the default folders from the “share” directory and you don't see any folders from packages, just the default folders from the “user” directory and any other folders that might have been added before. The path extensions provided by packages are completely under control of the PackageManager.