Dependency recursion is the way Deputy processes a Maven project.xml when you execute
the function 'Apply Rules' on it. The following is an outline of the algorithm used.
It gives you a detailed understanding of what Deputy does for you and how you can
influence it by defining appropriate rules.
The starter set of dependencies to decide on as to the versions to use and to
recurse over is always the set of dependencies literally defined in the
project.xml loaded into Deputy. Excluded from these are all indirect
dependencies potentially listed in the file. They will be ignored completely and
be (re-)computed instead. An indirect dependency is recognized by the
properties child element <top>false</top>. If the value is true or if the whole
element is absent, the dependency is considered to be a top-level (or: direct) dependency.
Now Deputy takes each top-level dependency found in the file and evaluates
the rule set of the project in order to decide which version of it to follow
If there is a removal rule for the dependency the dependency is ignored.
Else, step 2 is taken.
If there is a replacement rule for exactly this version of this artifact,
it is applied. Else, if there is a replacement rule for this artifact (being
non-specific about the version) it is applied.
Applying a replacement rule, in fact, is more than deciding which version of
an artifact to follow. The literal group id and/or artifact id and/or version
is replaced by some other group id and/or artifact id and or version and the
latter is followed recursively instead of the replaced one.
If a replacement rule could be applied the following steps will be applied on
the result of the replacement rather than on the original dependency.
If there is an enforcement rule for this artifact and version, it is
applied and the enforced artifact and version is tracked down rather than the
original one. Else, step 4 is taken.
The list of all versions available for the current artifact is retrieved.
It contains at least the original version but usually more. If the list contains
versions which are lower than the version required by the current dependee these
are cut off the list because they are too old. As an exception, too old versions
are not cut off and thus discarded, however, if the dependee is the root project
currently loaded into Deputy.
From the list produced in the previous step the version to further track down
recursively is now chosen as follows:
The first version in the list of versions is chosen. Since the list is ordered
descendingly this is the latest version available (often a SNAPSHOT).
If the version picked from the list is deprecated or if it is a SNAPSHOT and the
default rule is to take the latest release rather than a SNAPSHOT
and if there is at least one more candidate in the list, the version is discarded
and the next element in the list is chosen as candidate and inspected in the same way.
Else, the version picked is the end result of the choice process.
For each project selected according to the rules listed above, the algorithm
and the rules are applied recursively on this project's dependencies. Of
course, on all levels of the recursion only the rule set of the top project is