.exospkg XML reference

<< 点击显示目录 >>

主页  exOS使用助手 > exOS Automation Help > Development > exOS Package >

.exospkg XML reference

.exospkg 和配置元素之间的关系一节所述,所有设置(除极少数设置外)在 exOS 组件配置元素中均可见。这意味着可以在 Automation Studio 中编辑这些设置,而无需在 .exospkg 文件中定义它们。有关各种设置的进一步说明,请参阅配置元素。本节将介绍可能的值。

 

文件结构

.exospkg 文件的一般结构如下

   <?xml version="1.0" encoding="utf-8"?>
   <ComponentPackage .. >
       ..
   </ComponentPackage>

 

一般属性

<ComponentPackage> 具有以下属性:

oVersion:

用于检查不同版本 .exospkg 文件之间的兼容性。目前设置为 2.0.0

 

oErrorHandling:

定义 exOS 在编译或部署组件时应如何处理错误。可选项包括忽略、组件、目标。更多信息请参阅错误处理

 

oStartupTimeout:

在 Automation Studio 的 exOS 组件配置中不可见的设置。它定义了在另一个组件启动或部署程序被视为 "完成 "之前,组件所需的特定延迟时间。如果某个服务/进程的启动时间较长,而其他服务又依赖于该服务/进程,那么这一点就很重要。StartupTimeout 以秒为单位设置。默认值(如果未提供)为 0 秒。

 

oRestartEvent:

在 Automation Studio 的 exOS 组件配置中不可见的设置。它定义了组件重启的行为。默认设置为组件,即重启组件。目标设置规定,如果重启该组件,则所有其他组件也需要重启。在运行状态下,运行时服务受到监控,这与 ErrorHandling=Target 的效果相同(停止所有组件)。更多信息请参阅错误处理。可以设置 "忽略 "选项,以防止该组件被其他需要重启 "目标 "的组件重启(但不适用于组件的运行时关闭)。目前,exos-data 数据连接组件使用 RestartEvent=Target。

 

部署说明
 

<File>

FileName:

文件名相对于 .exospkg 文件的路径。

 

ChangeEvent:

更改事件设置定义了如何对文件更改做出反应。如果系统检测到该文件被添加、删除或修改,就会触发事件。更多信息请参阅文件

 

Ignore

不触发任何操作。

Restart

如果该文件有任何更改,组件将重新启动。
 

Reinstall

如果该文件有任何更改,组件将被重新安装(并重新启动)。

 

举例说明: 将 types.py 作为任意文件传输,以便在更改时重启组件。

 <File FileName="Linux\types.py" ChangeEvent="Restart"/>

 

<Service>

 服务 "部分配置了将在目标系统上执行的服务。输出将转发到 ExDeploy Logger。有关详细信息,请参阅Services

o类型:

安装 = 在安装 exOS 组件时启动此类型的服务。

移除 = 在移除 exOS 组件时启动此类型的服务。

启动 = 在启动运行时服务之前启动此类型的服务。

运行时 = 当 exOS 组件开始运行时启动此类型的服务。

 

指令:

提供命令的方式与在 shell 上执行命令的方式相同。在调用命令前,目录会更改为工作目录设置中提供的路径。

例子: 在启动运行时服务之前,从组件部署目录中复制 types.py 文件:

<Service Type="Startup" Command="cp types.py /home/user/types/"/>

 

工作目录:

工作目录允许指定执行命令的路径。如果未指定该属性,则使用组件的部署目录。

示例: 使用 /home/user/watertank 目录中的 node 运行 index.js 文件

<Service Type="Runtime" Command="node index.js" WorkingDirectory="/home/user/watertank"/>

 

<数据模型实例>

在 exOS 目标配置元素中选择 "组件配置 "时,特定组件的数据连接将使用 .exospkg 文件中的 DatamodelInstance 更新。有关详情,请参阅.exospkg 和配置元素之间的关系。它具有以下属性:

 

名称:

应用程序中使用 exos_datamodel_init() API 函数连接的数据模型实例的名称。默认情况下,这也是管理程序设置中配置的共享内存区域的名称。

 

共享内存大小:

默认情况下,共享内存区的大小为 200kB,这在大多数应用程序中已经足够。如果应用程序需要使用更大的共享内存分区,在 exOS 目标配置中选择 "组件配置 "时,可使用该属性自动分配新建共享内存区域的大小。
 

共享内存:

如果需要为共享内存使用另一个名称(而不是自动继承的 Name),可使用 SharedMemory 属性来指定此数据模型实例的共享内存分区名称。

 

端口

端口通常从 49001 开始自动编号,只有在绝对需要时才可通过此属性明确分配。如果目标系统上的 Linux-ufw 已启用,exostarget 配置中使用的端口会自动处理,因此如果 Linux 已启用防火墙,则无需为数据模型分配 "开放 "端口,只有在 "特殊情况 "下才考虑使用此选项。

 

构建

在源码包中,.exospkg 文件还包含构建说明。  有关详情,请参阅 AS 中的 exOS 构建链


As mentioned in the section Relation between .exospkg and configuration elements, all settings (besides a very few) are visible in the exOS Component configuration element. This means, they can be edited from Automation Studio, without defining them in the .exospkg file. For further explanation of the various settings, see Configuration Elements. This section describes the possible values.

File structure

The general structure of the .exospkg file needs to look like the following

    <?xml version="1.0" encoding="utf-8"?>
    <ComponentPackage .. >
        ..
    </ComponentPackage>

General attributes

The <ComponentPackage> has the following attributes:

Version:

used for compatibility checks between different versions of .exospkg files. Currently set to 2.0.0

ErrorHandling:

Defines how exOS should treat errors when compiling or deploying the component. Possible options are Ignore, Component, Target. See Error Handling for further information.

StartupTimeout:

Setting which is invisible in the exOS Component configuration in Automation Studio. It defines the specific delay time that the component requires before another component can be started or the deployment procedure is considered to be 'Done'. This can be important if a service/process has a long boot time and other services are dependent on this one. StartupTimeout is set in seconds. The default value (if not provided) is 0 seconds.

RestartEvent:

Setting which is invisible in the exOS Component configuration in Automation Studio. It defines the behaviour of a component restart. The default setting is Component, meaning it restarts the component. The Target setting dictates, that if this component is restarted, all other components need to be restarted as well. In Operational state, where the runtime services are monitored, this has the same effect as the ErrorHandling=Target (stop all components). See Error Handling for further information. The Ignore option can be set in order to prevent this component to be restarted by other components requiring a Target restart (does however not apply to the runtime shutdown of components). Currently, the exos-data data connection component uses the RestartEvent=Target.

Deployment instructions
 

<File>

FileName:

The path to the filename relative to the .exospkg file.

ChangeEvent:

The Change event setting defines how to react on a change of this file. The event is triggered if an add, remove, or modification of this file is detected by the system. See Files for more information
 

Ignore

No action is triggered.
 

Restart

On any change of this file, the component is restarted.
 

Reinstall

On any change of this file, the component is reinstalled (and restarted).

Example: Transfer types.py as an arbitrary file that restarts the component at change.

  <File FileName="Linux\types.py" ChangeEvent="Restart"/>

<Service>

The Services section configures the services that shall be executed on the target system. The Output is forwarded to the ExDeploy Logger. See Services for more information.

Type:

Install = Services of this type are started whenever an installation of the exOS component shall be carried out.

Remove = Services of this type are started whenever a removal of the exOS component shall be carried out.

Startup= Services of this type are started before starting the Runtime Services.

Runtime = Services of this type are started when an exOS component shall become operational.
 

Command:

A command has to be provided in the same way as if it was executed on a shell. Before calling the command, the directory is changed to the path provided in the Working directory setting.

Example: copy types.py file from the component deployment directory before starting runtime services:

  <Service Type="Startup" Command="cp types.py /home/user/types/"/>

WorkingDirectory:

The Working directory allows to specify a path at which the command shall be executed. If this attribute is not specified, the deployment directory of the component is used.

Example: run the index.js file with node in the /home/user/watertank directory

  <Service Type="Runtime" Command="node index.js" WorkingDirectory="/home/user/watertank"/>

<DatamodelInstance>

When selecting the Component Configuration in the exOS Target configuration element, the data connection for the specific component is updated with the DatamodelInstance from the .exospkg file. Please see Relation between the .exospkg and configuration elements for more on this. It has the following attributes:

Name:

Name of the datamodel instance used in the application to connect using exos_datamodel_init() API function. This is per default also the name of the shared memory area configured in the Hypervisor settings.
 

SharedMemorySize:

By default, shared memory areas are added with the size of 200kB, which is suffient in most applications. Should there be a need to use larger shared memory partitions for the applications, this attribute can be used to automatically assign the size of the newly created shared memory area when selecting the Component Configuration in the exOS target configuration.
 

SharedMemory:

Should there be a need to use another name for the shared memory than the automatically inherited Name, the SharedMemory attribute can be used to specify the name of the shared memory partition for this datamodel instance.
 

Port:

Ports are normally auto numbered from 49001 and upwards and should only be explicitly assigned via this attribute if absolutely needed. The ports used in the exostarget configuration are handled automatically on the Linux-ufw if this is enabled on the target system, therefore there is no need to assign "open" ports to datamodels if Linux has the firewall active, and this option should only be considered for "special cases".

Build

In source packages, the .exospkg file also contains build instructions. Please see exOS build-chain in Automation Studio for more on this.