Dependency Recursion

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 recursively:

  1. If there is a removal rule for the dependency the dependency is ignored. Else, step 2 is taken.
  2. 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.
  3. 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.
  4. 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.
  5. 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 used.