equinox
dynamic plugins > dependencies API
|
|
The dependencies API is being proposed as a general way of solving dependencies
between versioned elements. This API is being created to be used in the new
dynamic registry resolution, but we believe it can be useful in other similar
scenarios (e.g. features in the update manager).
The idea behind the dependency API is based on the following concepts:
- an element has a unique identity (a pair <element-set-id,
version-id>) and a set of dependencies on other elements. An element is
said resolved if all mandatory dependencies are satisfied. Otherwise,
it is said unresolved.
- a version id allows to distinguish between different elements
in an element set. Different version-ids have different magnitudes.
- an element set groups elements whose id differs only by
the version id. Element sets are connected to each other by asymmetric binary
associations where one of the element sets is said as depending on the other.
An element set A is said to depend on an element set B if at least one element
in A depends on any element in B. An element set is said root if
it does not depend on any other element set, and leaf if it is not
depended upon by any other element set. It is valid for an element set to
be simultaneously root and leaf.
- a dependency is an object described by the following attributes:
- an element set identifier, which defines on which element set the dependency
relies on;
- a required version identifier, which may be null, depending on the match
rule;
- a match rule, which is a predicate that evaluates whether a given available
version identifier is sufficient for the required version identifier.
- a resolved version identifier, which is set by the resolution algorithm,
and determines which available version identifer actually satisfied the
dependency (if any).
- a dependency system is a acyclic directed graph whose vertices
are element sets and edges between them exist whenever an element set depends
on another (any two element sets cannot depend mutually on each other).
- the resolution process is a three-pass traversal that determines
the resolution status for all elements and dependencies in all element sets
in the system:
- 1st pass: starts from the roots going to the leaves. For each element
set visited, determine which elements are satisfied (an available
element is satisfied if all of its mandatory dependencies can be satisfied
by satisfied elements from the element sets depended upon).
- 2nd pass: starts from the leaves going to the roots. For each element
set visited, determine which elements are selected (a satisfied
element is said selected according to the selection policy defined for
the system).
- 3rd pass: again, starts from the roots going to the leaves. For each
element set visited, determine which elements are resolved (a
selected element is resolved if all of its mandatory dependencies can
be satisfied by resolved elements from the element sets depended upon).
- a resolution delta is generated as a result of the resolution
process. The delta reports which elements transitioned between the unknown(not
in the registry)/resolved/unresolved states (transitions
are allowed in any direction between any pair of these three states), and
which resolved elements had changes in their dependency resolution status
(already resolved dependencies were resolved against different versions, and/or
optional dependencies transitioned between resolved/unresolved statuses) since
the last resolution operation.