Difference between revisions of "Zh/Documentation/DevGuide/WritingUNO/File Naming Conventions"

Revision as of 06:07, 15 August 2008

建议您根据以下命名模式来命名 UNO 组件库和 UNO 软件包:

 <NAME>[<VERSION>].uno.(so|dll|dylib|jar) 

此建议适用于共享库和 Java 存档文件,以及由 pkgchk 部署的 UNO 软件包,如 扩展 所述。

此文件名约定产生如下文件名:

• component.uno.so
• component1.uno.dll
• component0.1.3.uno.dylib
• component.uno.jar

<NAME> 应为描述性名称,可选择使用如下所示的版本信息进行扩展,版本信息之后是字符 .uno 以及必要的文件扩展名。

术语 .uno 位于特定于平台的扩展名旁边,以强调这是共享库、jar 或 zip 文件的特殊类型。

通常,共享库或 jar 文件必须使用 UNO 注册才能发挥作用,因为它的共享库接口只包含组件操作。压缩文件不能容易地被识别为 UNO 软件包。在这两种情况下,.uno 标签将告知用户,组件或软件包文件是与 UNO 一起使用的。

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:

 <VERSION> = <MAJOR> [.<MINOR> [.<MICRO>]]
 <MAJOR>   = <NUMBER>
 <MINOR>   = <NUMBER>
 <MICRO>   = <NUMBER>
 <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 OpenOffice.org installation is already well defined by the version and build number of the installed OpenOffice.org 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.

Template:Documentation/Note

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 libc.so.6, libstdc++.so.3.0.1, and libstlport_gcc.so

UNO runtime libraries

such as libcppu.so.3.1.0 and libcppuhelpergcc3.so.3.1.0

[PRODUCTNAME] libraries

such as libsvx644li.so

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