下面的示例解释了如何在 Node.js 包中对文件和服务进行参数化。
示例软件包WaterTank包含创建LinuxDebian软件包的源代码、一个JavaScript文件、一个相应的AR库和一个使用AR库的示例AR任务。该软件包在相应的描述文件WaterTank.exospkg中进行了描述。
根据描述文件中的设置，引用该软件包新建的 exOS 组件将如下所示：
文件"部分包括两个文件条目，分别引用Debian软件包和JavaScript文件。文件名指向逻辑视图中相对于exOS软件包的文件名。请注意，Debian软件包本身并不是exOS软件包的一部分，因为它只在AS项目的构建过程中构建。
根据这些条目，部署机制将负责把文件传输到Linux目标机。根据"更改事件"（Changeevent）设置，如果JavaScript文件发生更改，即传输到目标机（作为新文件或修改后的文件）或从目标机中删除，组件将重新启动。不过，Debian软件包的更改（如重新编译）将触发组件的重新安装。
服务"部分包含几个条目：
首先，定义了一个安装程序服务，在组件安装过程中执行。该安装服务利用dpkg在系统中安装Debian软件包。
第二个条目描述了相应的移除服务。移除服务也是利用dpkg从系统中移除Debian软件包。
在实际启动组件之前，会执行一个启动服务。在这里，JavaScript文件会被复制到安装.deb软件包内容的相同位置。(对于.deb包，该位置在CMakeLists.txt构建配置中提供）。有了这个启动服务，只需更改JavaScript文件，而无需重新编译或重新安装整个exOS组件。
最后，定义运行时服务是为了运行Node应用程序。它的工作目录就是上一步中复制JavaScript文件的位置。
这个exOS组件展示了一个更复杂的示例，其中包含一个Debian软件包和一个Node.js脚本。Debian软件包本身不是预制的，而是在AS的构建过程中根据源代码创建的，然后才传输并安装到目标机上。
在目标端，Debian软件包应使用标准的Debian软件包管理进行安装和移除，而Node.js应用程序只需复制到目标目录并从那里启动即可。
这个例子展示了exOS的灵活性，以及如何处理高级情况和要求。
The following example explains how files and services are parametrized in a Node.js package.
The example package WaterTank contains source code that creates a Debian package for Linux, a JavaScript file, an according AR library, and a sample AR task using the AR library. The package is described in the according description file WaterTank.exospkg.
According to the settings in the description file, a newly created exOS Component referencing this package will look like the following:
The Files section consists of two file entries that reference the Debian package and the JavaScript file. The file names point to the file names relative to the exOS Package as seen in the Logical View. Note that the Debian package itself is not part of the exOS Package as it is only built during the build process of the AS project.
Due to these entries, the deployment mechanism will take care of transferring the files to the Linux target. According to the Change event setting, the component shall be restarted, if the JavaScript file is changed, i.e. transferred to the target (as a new file or as a modified file) or deleted from the target. However, a change of the Debian package (e.g. due to a re-compilation) will trigger a re-installation of the component.
The Services section contains several entries:
First of all, an installer service is defined that is executed during the installation of the component. This installer service utilizes dpkg in order to install the Debian package on the system.
An according removal service is described in the second entry. Also the removal service makes use of dpkg to remove the Debian package from the system.
Before actually starting the component, a startup service is executed. Here, the JavaScript file is copied to the same destination to which also the contents of the .deb package is installed. (For the .deb package, this location is provided in the CMakeLists.txt build configuration.) Due to this startup service it is possible to simply change the JavaScript file without the need to re-compile or re-install the whole exOS Component.
Finally, the runtime service is defined to run the Node application. As its working directory it uses the location to which the JavaScript file has been copied in the previous step.
This exOS component showcases a more sophisticated example which contains a Debian package and a Node.js script. The Debian package itself is not pre-made, but is created from source code during the build process in AS before it is transferred and installed on the target.
On the target side, the Debian package shall be installed and removed using standard Debian package management, while the Node.js application is just copied to its destination directory and started from there.
This example shows the flexibility of exOS and how advanced situations and requirements can be handled.