文件命名约定
建议您根据以下命名模式来命名 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 一起使用的。
由于给定的命名模式仅是一个建议，有的组件共享库的名称中可能不包含 .uno 部分。因此，工具不应假设共享库是否包含 .uno。
<VERSION> 是可选的，并且应采用以下形式：
<VERSION> = <MAJOR> [.<MINOR> [.<MICRO>]] <MAJOR> = <NUMBER> <MINOR> = <NUMBER> <MICRO> = <NUMBER> <NUMBER> = 0 | 1–9 0–9*
共享库或 JAR 的文件名中使用版本标记主要适用于简单的组件，这些组件不是由扩展管理器部署的扩展的组成部分。这样的组件通常由单个共享库组成，并且不同版本采用不同的文件名会很有用，例如在错误报告中。
组件的版本是 OpenOffice.org 安装的一部分，它已由安装的 OpenOffice.org 本身的版本和内部版本号定义。
如何使用版本方案由开发者决定。您可以单独使用 MAJOR 或者按需要增加 MINOR 和 MICRO，以计算给定组件共享库的版本。
 |
如果使用版本，必须将其放在特定于平台的扩展名之前，永远不要放在扩展名之后。在 Linux 和 Solaris 中，习惯的做法是在 .so 后加入版本号，但是该版本号与此处使用的版本号意义不同。简言之，那些版本号将随共享库接口的更改而更改，而使用 component_getFactory() 等操作的 UNO 组件接口从不更改。
|
The following considerations give an overview of ways that a component can evolve: 以下注意事项概要介绍了开发组件的几种方法：
根据组件操作（例如 component_getFactory()）的定义，组件共享库的接口被认为是稳定的。
组件提供的 UNO 服务可以按以下方式更改：
- 兼容：通过更改组件文件中的实现但仍坚持其规范，或者通过在组件文件中添加新的 UNO 服务实现
- 不兼容：通过删除实现，或者通过从组件删除 UNO 服务
- 间接兼容：其中一个 UNO 服务更改兼容性时，组件也进行相应的更改。当服务规范通过附加的可选接口进行扩展而组件也调整为支持这些接口时，会出现这种情况。
当组件文件中的实现更改时，例如错误被修复时，这样的更改通常是兼容的，除非客户端依赖于该错误。客户端将错误视为一种功能，或者对错误的修复使客户端对该错误产生依赖时，会出现该结果。因此，开发者必须根据规范（而非实现）谨慎编程。
最后，组件共享库可以更改它对其他共享库的依赖性。这种依赖性的示例包括：
C/C++ 运行时库
- 例如 libc.so.6、libstdc++.so.3.0.1 和 libstlport_gcc.so
UNO 运行时库
- 例如 libcppu.so.3.1.0 和 libcppuhelpergcc3.so.3.1.0
[PRODUCTNAME] 库
- 例如 libsvx644li.so
依赖性的更改通常是不兼容的，因为它们依赖于组件环境的兼容或不兼容的更改。
| Content on this page is licensed under the Public Documentation License (PDL). |
