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

From Apache OpenOffice Wiki
Jump to: navigation, search
m
m
Line 31: Line 31:
  
  
−
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.
+
由于给定的命名模式仅是一个建议，有的组件共享库的名称中可能不包含 '''.uno''' 部分。因此，工具不应假设共享库是否包含 '''.uno'''。
  
−
<VERSION> is optional and should be in the form:
+
 
 +
<VERSION> 是可选的，并且应采用以下形式：
  
 
   <VERSION> = <MAJOR> [.<MINOR> [.<MICRO>]]
 
   <VERSION> = <MAJOR> [.<MINOR> [.<MICRO>]]
Line 41: Line 42:
 
   <NUMBER>  = 0 | 1–9 0–9*
 
   <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.
 
  
 +
共享库或 JAR 的文件名中使用版本标记主要适用于简单的组件，这些组件不是由'''扩展管理器部署的扩展'''的组成部分。这样的组件通常由单个共享库组成，并且不同版本采用不同的文件名会很有用，例如在错误报告中。
 +
 +
 +
组件的版本是 {{PRODUCTNAME}} 安装的一部分，它已由安装的 {{PRODUCTNAME}} 本身的版本和内部版本号定义。
 +
 +
 +
如何使用版本方案由开发者决定。您可以单独使用 MAJOR 或者按需要增加 MINOR 和 MICRO，以计算给定组件共享库的版本。
 +
 +
 +
{{Documentation/Note|如果使用版本，必须将其放在特定于平台的扩展名之前，永远不要放在扩展名之后。在 Linux 和 Solaris 中，习惯的做法是在 .so 后加入版本号，但是该版本号与此处使用的版本号意义不同。简言之，那些版本号将随共享库接口的更改而更改，而使用 <code>component_getFactory()</code> 等操作的 UNO 组件接口从不更改。}}
 +
 +
The following considerations give an overview of ways that a component can evolve: 以下注意事项概要介绍了开发组件的几种方法：
  
−
The version of components that are part of the {{PRODUCTNAME}} installation is already well defined by the version and build number of the installed {{PRODUCTNAME}} 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.
+
根据组件操作（例如 <code>component_getFactory()</code>）的定义，组件共享库的接口被认为是稳定的。
  
−
{{Documentation/Note|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 <code>component_getFactory()</code> etc. never changes.}}
 
  
−
The following considerations give an overview of ways that a component can evolve:
+
组件提供的 UNO 服务可以按以下方式更改：
  
−
A component shared library's interface, as defined by the component operations such as <code>component_getFactory()</code> is assumed to be stable.
+
* 兼容：通过更改组件文件中的实现但仍坚持其规范，或者通过在组件文件中添加新的 UNO 服务实现
 +
* 不兼容：通过删除实现，或者通过从组件删除 UNO 服务
 +
* 间接兼容：其中一个 UNO 服务更改兼容性时，组件也进行相应的更改。当服务规范通过附加的可选接口进行扩展而组件也调整为支持这些接口时，会出现这种情况。
  
−
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''
+
''C/C++ 运行时库''
−
:such as libc.so.6, libstdc++.so.3.0.1, and libstlport_gcc.so  
+
:例如 libc.so.6、libstdc++.so.3.0.1 和 libstlport_gcc.so  
  
−
''UNO runtime libraries''  
+
''UNO 运行时库''  
−
:such as libcppu.so.3.1.0 and libcppuhelpergcc3.so.3.1.0  
+
:例如 libcppu.so.3.1.0 和 libcppuhelpergcc3.so.3.1.0  
  
−
''[PRODUCTNAME] libraries''  
+
''[PRODUCTNAME] 库''  
−
:such as libsvx644li.so  
+
:例如 libsvx644li.so  
  
−
Dependency changes are typically incompatible, as they rely on compatible or incompatible changes of the component's environment.
+
依赖性的更改通常是不兼容的，因为它们依赖于组件环境的兼容或不兼容的更改。
  
 
{{PDL1}}
 
{{PDL1}}
  
−
[[Category:Documentation/Developer's Guide/Writing UNO Components]]
+
[[Category:文档/开发者指南/编写 UNO 组件]]

Revision as of 02:55, 18 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 一起使用的。


由于给定的命名模式仅是一个建议，有的组件共享库的名称中可能不包含 .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，以计算给定组件共享库的版本。


Template:Documentation/Note

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).
Retrieved from "https://wiki.openoffice.org/w/index.php?title=Zh/Documentation/DevGuide/WritingUNO/File_Naming_Conventions&oldid=89907"
Personal tools
In other languages