File Naming Conventions

From Apache OpenOffice Wiki
Jump to: navigation, search

As a recommendation, UNO component libraries should be named according to the following naming scheme:


This recommendation applies to shared libraries and Java archives,which are deployed by the Extension Manager as described in section Extensions.

This file name convention results in file names such as:


<NAME> should be a descriptive name, optionally extended by version information as shown below, followed by the characters .uno and the necessary file extension.

The term .uno is placed next to the platform-specific extension to emphasize that this is a special type of shared library, jar, or zip file.

Usually a shared library or jar has to be registered with UNO to be useful, as its shared library interface only consists of the component operations.

Since the given naming scheme is only a suggestion, there might be component shared libraries that do not contain the .uno addition in their names. Therefore, no tool should build assumptions on whether a shared library name contains .uno or not.

<VERSION> is optional and should be in the form:

 <NUMBER>  = 0 | 1–9 0–9*

Using the version tag in the file name of a shared library or jar is primarily meant for simple components that are not part of an extension deployed by the Extension Manager. Such components are usually made up of a single shared library, and different file names for different versions can be useful, for instance in bug reports.

The version of components that are part of the Apache OpenOffice installation is already well-defined by the version and build number of the installed Apache OpenOffice itself.

It is up to the developer how the version scheme is used. You can count versions of a given component shared library using MAJOR alone, or add MINOR and MICRO as needed.

Documentation note.png If version is used, it must be placed before the platform-specific extension, never after it. Under Linux and Solaris, there is a convention to add a version number after the .so, but that version number has different semantics than the version number used here. In short, those version numbers change whenever the shared library's interface changes, whereas the UNO component interface with the component operations component_getFactory() etc. never changes.

The following considerations give an overview of ways that a component can evolve:

A component shared library's interface, as defined by the component operations such as component_getFactory() is assumed to be stable.

The UNO services offered by a component can change:

  • compatibly : by changing an implementation in the component file but adhering to its specification, or by adding a new UNO service implementation to a component file
  • incompatibly: by removing an implementation, or by removing a UNO service from a component
  • indirectly compatibly: when one of the UNO services changes compatibility and the component is adapted accordingly. This can happen when a service specification is extended by additional optional interfaces, and the component is altered to support these interfaces.

When an implementation in a component file is changed, for instance when a bug is fixed, such a change will typically be compatible unless clients made themselves dependent on the bug. This can happen when clients considered the bug a feature or worked around the bug in a way that made them dependent on the bug. Therefore developers must be careful to program according to the specification, not the implementation.

Finally, a component shared library can change its dependencies on other shared libraries. Examples of such dependencies are:

C/C++ runtime libraries

such as,, and

UNO runtime libraries

such as and

[PRODUCTNAME] libraries

such as

Dependency changes are typically incompatible, as they rely on compatible or incompatible changes of the component's environment.

Content on this page is licensed under the Public Documentation License (PDL).
Personal tools
In other languages