OMNeT++仿真之NED语言第三章packages

本文翻译官方文档ned语言第三章第14.1节内容：package的定义及package.ned文件

原英文文档：

3.14 Packages

Having all NED files in a single directory is fine for small simulation projects. When a project grows, however, it sooner or later becomes necessary to introduce a directory structure, and sort the NED files into them. NED natively supports directory trees with NED files, and calls directories packages. Packages are also useful for reducing name conflicts, because names can be qualified with the package name. 

NOTE
NED packages are based on the Java package concept, with minorenhancements. If you are familiar with Java, you'll find littlesurprise in this section. 

3.14.1 Overview

When a simulation is run, one must tell the simulation kernel the directory which is the root of the package tree; let's call it NED source folder. The simulation kernel will traverse the whole directory tree, and load all NED files from every directory. One can have several NED directory trees, and their roots (the NED source folders) should be given to the simulation kernel in the NED path variable. The NED path can be specified in several ways: as an environment variable (NEDPATH), as a configuration option (ned-path), or as a command-line option to the simulation runtime (-n). NEDPATH is described in detail in chapter [11]. 

Directories in a NED source tree correspond to packages. If NED files are in the <root>/a/b/c directory (where <root> is listed in NED path), then the package name is a.b.c. The package name has to be explicitly declared at the top of the NED files as well, like this: 
package a.b.c;

The package name that follows from the directory name and the declared package must match; it is an error if they don't. (The only exception is the root package.ned file, as described below.) 

By convention, package names are all lowercase, and begin with either the project name (myproject), or the reversed domain name plus the project name (org.example.myproject). The latter convention would cause the directory tree to begin with a few levels of empty directories, but this can be eliminated with a toplevel package.ned. 

NED files called package.ned have a special role, as they are meant to represent the whole package. For example, comments in package.ned are treated as documentation of the package. Also, a @namespace property in a package.ned file affects all NED files in that directory and all directories below. 

The toplevel package.ned file can be used to designate the root package, which is useful for eliminating a few levels of empty directories resulting from the package naming convention. For example, given a project where all NED types are under the org.acme.foosim package, one can eliminate the empty directory levels org, acme and foosim by creating a package.ned file in the source root directory with the package declaration org.example.myproject. This will cause a directory foo under the root to be interpreted as package org.example.myproject.foo, and NED files in them must contain that as package declaration. Only the root package.ned can define the package, package.ned files in subdirectories must follow it. 

Let's look at the INET Framework as example, which contains hundreds of NED files in several dozen packages. The directory structure looks like this: 

INET/
    src/
        base/
        transport/
            tcp/
            udp/
            ...
        networklayer/
        linklayer/
        ...
    examples/
        adhoc/
        ethernet/
        ...

The src and examples subdirectories are denoted as NED source folders, so NEDPATH is the following (provided INET was unpacked in /home/joe):

/home/joe/INET/src;/home/joe/INET/examples

Both src and examples contain package.ned files to define the root package:

// INET/src/package.ned:
package inet;

// INET/examples/package.ned:
package inet.examples;

And other NED files follow the package defined in package.ned:

// INET/src/transport/tcp/TCP.ned:
package inet.transport.tcp;

翻译：

3.14包装
将所有NED文件放在一个目录中对于小型模拟项目来说是很好的。然而，当项目增长时，迟早需要引入目录结构，并将NED文件排序到其中。NED本机支持具有NED文件的目录树，并调用目录包。包对于减少名称冲突也很有用，因为名称可以用包名称限定。
注释
NED包基于Java包的概念，并进行了一些改进。如果您熟悉Java，那么在本节中您会发现一些小惊喜。
3.14.1概述
当模拟运行时，必须告诉模拟内核包树的根目录；让我们称之为NED源文件夹。模拟内核将遍历整个目录树，并从每个目录加载所有NED文件。可以有几个NED目录树，它们的根（NED源文件夹）应该在NED路径变量中提供给模拟内核。NED路径可以通过多种方式指定：作为环境变量（NEDPATH）、配置选项（NED路径）或模拟运行时的命令行选项（-n）。NEDPATH在第[11]章中有详细描述。
NED源树中的目录对应于程序包。如果NED文件位于<root>/a/b/c目录中（其中<root>列在NED路径中），则包名称为a.b.c。包名称也必须在NED文件的顶部明确声明，如下所示：
一揽子a.b.c；
目录名后面的包名和声明的包必须匹配；如果他们不这样做，那就是一个错误。（唯一的例外是根package.ned文件，如下所述。）
按照惯例，包名都是小写的，以项目名（myproject）或反向域名加上项目名（org.example.myproject）开头。后一种惯例会导致目录树以几级空目录开头，但这可以通过顶级包来消除。
名为package.NED的NED文件有一个特殊的作用，因为它们代表整个包。例如，package.ned中的注释被视为包的文档。此外，package.ned文件中的@namespace属性会影响该目录和下面所有目录中的所有ned文件。
顶层package.ned文件可用于指定根包，这对于消除由包命名约定导致的一些级别的空目录很有用。例如，给定一个所有NED类型都在org.acme.foosim包下的项目，可以通过在源根目录中创建一个package.NED文件，并使用包声明org.example.myproject来消除空目录级别org、acme和foosim。这将导致根目录下的目录foo被解释为包org.example.myproject.foo，并且其中的NED文件必须将其作为包声明包含。只有根package.ned可以定义包，子目录中的package.nd文件必须跟在它后面。
让我们以INET框架为例，它在几十个包中包含数百个NED文件。目录结构如下所示：

INET/
    src/
        base/
        transport/
            tcp/
            udp/
            ...
        networklayer/
        linklayer/
        ...
    examples/
        adhoc/
        ethernet/
        ...

src和examples子目录表示为NED源文件夹，因此NEDPATH如下（前提是INET在/home/joe中解包）：

/home/joe/INET/src;/home/joe/INET/examples

src和examples都包含用于定义根包的package.ned文件：

// INET/src/package.ned:
package inet;

// INET/examples/package.ned:
package inet.examples;

其他NED文件遵循package.NED中定义的程序包：