Show TOC

 Dependency Control ListsLocate this document in the navigation structure

The dependency control list for a package is a list of some (or all) interfaces that are external to and visible to the client package. Only objects that are exposed in interfaces of this list may be used by objects of the package and objects of its subpackages. In this way, dependencies can be defined in a top-down approach.

In order not to have to repeat the settings for the superpackage in each subpackage, it is possible to inherit the specifications of the superpackage and, from there, to refine them further.

The dependency control list is represented through an inclusion list and an exclusion list. In both of these lists, external, visible interfaces and external, visible interface lists can be included. If an invisible interface is part of either of the above lists, then the package check ignores this entry.

Dependency control lists limit the use of certain interfaces. The validity of the entries in both lists can be limited to:

  • the direct content of the reference package (without subpackages)
  • the direct content of the reference package and individual subpackages, or
  • individual subpackages (without the direct content of the reference package itself).

An entry is thus valid for a certain package if:

  • the package is the reference package itself or a direct subpackage of the reference package and the corresponding entry was not limited - with regard to its validity - solely to other packages, or
  • the package is a direct or indirect subpackage of such a direct subpackage of the reference package for which the entry is valid - in accordance with the above rule.
  •  

Entries in the exclusion list represent use prohibition and can be active at certain levels called exclusion levels. There are the following levels:

  • Deactivated, with warnings: Uses that rely on this dependency cause warnings during syntax check or activation and will be logged.
  • Active: Uses that require this dependency are forbidden and cause syntax errors or runtime errors. An entry in an exclusion list is called "active" if a use that contradicts the entry causes an error in the respective context.

For the use of an interface through a client package, the following limitations exist:

  • In a relevant inclusion list, there is no entry for the respective interface that is valid for the client package; and no such entry is "inherited" from the dependency control list of the superpackage (see below): in this case, use of the interface by the client package is not possible.
  • In a relevant exclusion list, a valid, active entry for the client package exists for the respective interface: then the use of the interface by the client package is not possible.
  • In a relevant exclusion list, a valid, non-active entry for the client package exists for the respective interface: then use is only possible within the rules of the respective exclusion level - provided there is no stronger limiting exclusion level set by relevant exclusion lists through other entries valid for the client package and provided the use was not fully forbidden through a different limitation.

The limitations defined by the dependency list of the reference package for the use of an interface by a client package are calculated according to the following rules:

  • If one or several entries exist for the respective interface in the inclusion list of the reference package, the entry with the least limitations for the respective client package applies. In addition, you have all the limitations that are defined in entries in the dependency control lists of the superpackages as well as the exclusion list of the reference package that are valid for the respective client package.
  • If there is no entry for the respective interface in the inclusion list of the reference package and if the switch for inheriting the dependency control list is not set, the respective interface cannot be used either by the reference package or by its subpackages.
  • If there is no entry for the respective interface in the inclusion list of the reference package and if the switch for inheriting the dependency control is set, the dependency control list of the superpackage applies.

In addition, you have all the limitations that are defined in entries in the dependency control lists of the superpackages as well as the exclusion list of the reference package that are valid for the respective interface. Therefore, the following rules apply for the use of an object:

  • The use of interfaces from subpackages is allowed if these interfaces are visible - that is, the interfaces have not excluded the client package in their access control list.
  • The use of an external object is allowed only if there is a usable, external package interface that contains the object.

An external package interface is usable from within a client package if it is any one of the following:

  • a package interface of a direct or indirect superpackage and the use of this package interface would be allowed for the package within the framework of the limitations defined by the dependency control list of the superpackage
  • a visible package interface of a sibling package
  • a visible package interface of a sibling package of a direct or indirect superpackage and its use is allowed by its own dependency control list (this may include the inheritance of the dependency control list of the superpackage and may not contradict the dependency control lists of all superpackages).

In real terms, this means that at every level of the hierarchy interfaces of sibling packages are only usable if they are explicitly listed as allowed in the dependency control list of the client package. For the use of interfaces that are external with regard to the superpackage, new entries must be created in the dependency control list (if the switch for inheriting the dependency control list of the superpackage is set) only if the permissions adopted from the superpackage for the package and its subpackages are to be limited.

The following example illustrates the use of dependency control lists:

In the above figure:

  • in the dependency control list of P2, the use of interfaces W and V from package P3 is allowed for subpackage P1
  • in the dependency control list of P1, the use of everything (straight off) that was allowed by the dependency control list of the superpackage and expressly interface V is allowed for subpackage P0. The express permission to use V would not have been necessary since V is also already covered by the pseudo entry '*'
  • P0 does not define its own dependency control list and thus "inherits" the one from P1
    Tip

    Dependency Control Lists are optional for packages, and a package may not have one.